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PREFACE 



Multics system administration software controls the use of system resources 
and keeps records about how they are used. It supports rationing of resources, 
provides system security services, and produces usage reports and bills as required. 



The administrative and resource control functions of Multics compose a sizeable 
subsystem. They are designed to be expanded or optionally bypassed and to allow 
flexibility for each Multics site. 



The Multics system allows a maximum of four administrative identities: the 
project administrator, the registration and accounting administrator (referred 
to as the accounting administrator), the system security administrator, and the 
system administrator. The only administrator each site must have is a system 
administrator . 



The reference manuals for Multics administrators are collectively referred 
to as the Multics Administrators* Manual ( MAM) . Throughout this document , references 
to the MAM are as follows: 



Document 



Referenced In Text As 



Project 

(Order No. AK51) 



MAM Project 



Registration and Accounting 
(Order No. kS'UEl 



MAM Accounting 



System 

(Order No. AK50) 



MAM System 



Resource Control 
(Order No. CC7i|) 



MAM RCP 



Communications 
(Order Ho. CCl5) 



MAM Communications 



The information and specifications in this document are subject to change without notice. This 
document contains information about Honeywell products or services that may not be available 
outside the United States. Consult your Honeywell Marketing Representative. 
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The MAM Communications is a guide to the operation of the Multics 
Communication System. This manual includes information on terminal types, line 
types, and channel management. 



The Programmer's Reference manual (see below) contains general user 
information about terminal use and communications input/output. Readers of the 
MAM Communications should be familiar with the information in the Programmer's 
Reference . 



One of the responsibilities of the system administrator is specifying 
procedures used by the operators. These procedures and all operator commands 
are described in the Multics Operator ' s Handbook , Order No. AM81 . For 
convenience, this handbook is referenced throughout this document as the MOH. 



The Multics Bulk Input/Output manual (Order No. CC34) contains information 

needed by system administrators and operators for the management of bulk 

input/ output . For convenience, this manual is referred to throughout this 
document as Multics Bulk I/O. 



The Multics Communication System manual, Order No. AN85, contains a 
complete description of the software that makes up the Multics Communication 
System, including the portion of it in the Multics supervisor, the software for 
the Front-End Network Processor (FNP), implementation details, and a glossary of 
technical terms specific to the Multics Communication System. 



The following are the primary reference manuals for user and system 
programmers of the Multics system. These manuals contain general information 
and are referenced throughout this document. For convenience, these references 
are as follows: 



Document 



Referenced in Text as 



Multics Programmer ' s Reference Manual 
(Order No . AG91 ) 



Programmer's Reference 



Multics C ommands and Active Functions Commands 
(Order No. AG92) 

Multics Subroutines and 1/0 Modules Subroutines 
(Order No. AG93) 



Significant Changes in C C75 - 01 B 

Throughout the manual, cross-references have been rectified in those cases 
where the reader is referred to an obsolete manual, and it is not apparent where 
the information can now be found. 

The Multics X.25 interface is now certified for use with TELENET and UNINET 
networks . 

A new command, set_x25_packet_threshold , is described in Section 7. 

The paGket_threshold and collect parameters of the TTF description for X.25 

channels are included in Appendix A. 

Also documented in Appendix A is the capability to connect to a foreign 
system from a terminal logged into Multics, using a protocol converter. 
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SECTION 1 



OVERVIEW OF MULTICS COMMUNICATION SYSTEM 



The Multics Communication System effects the transfer of data between the 
Multics viFtual m^etfro^'y and vaFious rem-ote devices (pr-iiBaFily t-erfn-inals) over 
communications channels. This manual is concerned with the Multics 
Communication System as it appears to a system administrator, and it also 
discusses the specification and management of channels. For a description of 
the internal workings of the Multics Communication System, see the Multics 
Communication System Manual, Order Number AN85. 



The bulk of the Multics Communication System resides in the Multics 
supervisor and in a separate machine, the Front-End Network Processor (FNP). 
There may be up to eight FNPs on a Multics system. The user-ring and supervisor 
portions of the Multics Communication System are principally concerned with 
terminal management, while the primary responsibility of the FNP is channel 
management. The determination of the number and types of channels to manage, 
however, comes in part from the physical configuration, and in part from a 
user-ring data base, the channel definition table (CDT). The CDT is maintained 
by the system administrator; its contents are described in Section 4. 



TERMINALS AND CHANNELS 



The term "channel" (or "communications channel"), as used in this manual, 
refers to the logical connection between the system and a remote input/output 
device via an FNP. This includes a physical connection, which may go through a 
telephone system or a private communications network, or may consist of one or 
more hardwired cables. Normally, there is a one-to-one correspondence between 
logical connections and physical connections, except in the case of multiplexed 
channels, described later in this section. 



The word "terminal" is used to refer to the device itself; it may be an 
ordinary interactive terminal, or it may be a computer controlling one or more 
peripheral devices. This manual is concerned primarily with channels and 
channel management; the use and control of terminals is described in the 
Programmer's Reference manual. 



FNPS, CONTROLLERS, ADAPTERS, AND SUBCHANNELS 



An FNP is either a Datanet 6670 (model 6651, 6661, or 6678) or a Datanet 
6600 (model 6652). (An earlier version of the Datanet 6600, known as a Datanet 
355, can also be used). The type of FNP is specified in the CDT (as explained 
in Section U) in order to account for minor software differences between the two 
machines . 
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Each FNP is connected to a Multics input/output multiplexer (TOM) by means 
of a peripheral of the FNP called the direct interface adapter (DIA), and a DI 
channel in the lOM. A Datanet 6670 interfaces to communications channels through 
a device known as a high-speed multiline controller, or HMLC. A Datanet 6600 
interfaces to communications channels through devices called line adapters, which 
are of two types: a low-speed line adapter (LSLA) and a high-speed line adapter 
(HSLA). Each controller or adapter has subchannels to which the individual 
communications channels (sometimes called "lines") are connected. 



HMLC Subchannels 



An HMLC handles synchronous channels at speeds ranging from 1,200 to 72,000 
baud, or asynchronous channels at speeds ranging from 110 to 19,200 baud. A 
Datanet 6670 can have up to 12 HMLCs, with each one capable of supporting up to 
eight subchannels (with a maximum combined speed of 72, 000 baud) . For compatibility, 
HMLCs are discussed in this manual in terms of HSLAs (the Datanet 6670 has no 
equivalent to the LSLA). Thus, four HMLCs are the equivalent of one HSLA, since 
an HSLA can support up to 32 subchannels (see below). 



LSLA Subchannels 



An LSLA handles asynchronous channels only, at speeds ranging from 110 to 
300 baud. Ech LSLA is logically divided into 52 "time slots"; a 
1 0-character-per-second (110 baud) subchannel takes up one time slot, a 
15-character-per-second (13^.5 or 150 baud) subchannel takes up two time slots, 
and a 30-character-per-second (300 baud) subchannel takes up three time slots. 
Thus, each LSLA can have a maximum of seventeen 300-baud channels, or fifty-two 
110-baud channels, or some other number in between depending on the mix of 
speeds. A Datanet 6600 can have up to six LSLAs; a Datanet 6670 has no equivalent 
to the LSLA. 



HSLA Subchannels 



An HSLA handles synchronous channels at speeds ranging from 1,200 to 72,000 
baud, or asynchronous channels at speeds ranging from 110 to 19,200 baud. A 
Datanet 6600 can have up to three HSLAs, with each one capable of supporting up 
to 32 independent subchannels (although memory constraints may limit the efficacy 
of such a configuration; see Appendix B). A Datanet 6670 can also have the 
equivalent of up to three HSLAs, or one for every four HMLCs. 



MULTIPLEXED CHANNELS 



The device associated with a physical channel may be some kind of concentrator 
that controls multiple terminals (examples of such concentrators include the 
Honeywell VIP 7700 series and the IBM Model 3270 series). For some types of 
concentrator, the Multics Communication System is capable of treating each terminal 
as a separate logical channel, if so instructed by the CDT. In this case, the 
channel occupied by the concentrator is called a multiplexed channel, and the 
concentrator is referred to as a multiplexer; the logical channels associated 
with the individual terminals are called subchannels of the multiplexer. The 
multiplexed channel and its subchannels must all be defined in the CDT. In 
theory, a subchannel of a multiplexer might itself be multiplexed. Such multiplexing 
can be carried to any number of levels. 
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Since an FNP controls many channels, but communicates with the central 
system over a single channel (the DIA), the FNP may be regarded as a multiplexer. 
In fact, as indicated in Section 5, the operator commands used to control multiplexers 
(load_mpx, start_mpx, etc.) are also used to control FNPs. Furthermore, frequent 
reference is made in this manual to a channel's multiplexer or "parent multiplexer" 
(i.e., the multiplexer of which it is a subchannel); when the channel referred 
to is a physical FNP channel, the parent multiplexer is the FNP. 



Appendix A contains detailed information on how to configure certain 
system-supplied multiplexers. 



CHANNEL NAMES 



Each communications channel has a unique name that identifies the FNP, 
controller or adapter, and subchannel through which it is connected. Subchannels 
of multiplexed channels are identified by additional components in their names. 
For example, "a.h102" identifies channel 02 of HSLA 1 on FNP a. The format of a 
channel name is described in detail in the Programmer's Reference manual. 



INITIALIZATION 



When the system comes up and the answering service is initialized, each FNP 
specified in the CDT is loaded (provided that a corresponding FNP card appears 
in the config deck, and that the CDT does not specify a service type of "inactive" 
for the FNP). If the FNP is successfully loaded, all the communications channels 
on that FNP are initialized. For nonmultiplexed channels, this means "listening" 
to the channel, i.e., putting it in a state in which dialups are possible. For 
multiplexed channels, initialization means setting up various internal data bases 
and initializing each subchannel of the multiplexer. 



and the multiplexer (and its subchannels) is reinitialized. Similarly, if an 
FNP crashes, it is automatically reloaded, and all its channels reinitialized. 
For information on how to control the loading and initialization of multiplexers 
(including FNPs), see Sections 5 and 6. 



CONSISTENCY OF CONFIGURATION 



In order for a channel or set of channels to be usable, the data bases 
describing the channel configuration must be consistent with each other, and 
with the physical configuration. In particular, the following points should be 
observed : 

• All channels must be represented in the channel definition table (CDT). 
Tf channels are missing from the CDT, they can be added and the CDT 
replaced as described in Sections ^ and 5; use of such added channels 
requires the reloading of a multiplexer, as described in Section 5. 
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• The attributes and configuration of each channel as described in the 
CDT must agree with its actual characteristics; specifically, it must 
be cabled to the correct subchannel of the correct LSLA or HSLA, and 
the appropriate modems (if any) must be installed with the correct 
options (see Section 3 for more information about modems). If the CDT 
and the configuration disagree, either the CDT should be corrected (as 
indicated above) or the physical configuration should be adjusted to 
agree with the CDT. In the latter case, the multiplexer probably does 
not need to be reloaded; however, the channel may have to be reinitialized 
by using the attach and detach commands (see Section 5). 

• Any FNP that is t-o be used must be represented by an FNP card in the 
BOS config deck, and must be cabled to the lOM channel specified on 
the FNP card. (The config deck is described in the MOH.) If the FNP 
card is specified incorrectly or is missing, the FNP is unusable until 
the next Multics bootload; the config deck has to be corrected from.- 
BOS between bootloads. See the MOH for more information. 

• Each FNP must also be represented by an entry in the CDT; the FNP core 
image specified in this entry must exist, and must support at least as 
many LSLAs and HSLAs as are specified in the CDT entry. If any channels 
on that FNP require special communications protocols (see Section 3), 
the FNP modules that implement those protocols must be included in the 
core image (see Section 6). If the core image and the CDT entry 
disagree, either the CDT should be replaced, or the core image should 
be recreated using the bind_fnp command (described in Section 7). In 
either case, the FNP must be reloaded before use. 

• A site may implement its own communications protocol(s) and add its 
own FNP control tables module(s) to the core image. The line types 
ASYNC_1, ASYNC_2, ASYNC_3, SYNC_1 , SYNC_2, and SYNC_3 are reserved for 
such site-defined protocols. For information on the preparation of 
control tables modules, see the Multics Communication System manual. 

• All terminal types specified in the CDT, as well as any others that 
the site intends to support, must be represented by entries in the 
terminal type table (TTT). A standard TTT is supplied with the system; 
however, if the site has terminals other than those specified in the 
standard TTT, the system administrator may add entries for those terminals 
to the terminal type file (TTF) and replace the system TTT 
(>system__control__1 >ttt ) . In certain cases, individual users may wish 
to define their own terminal types in a private TTT; for this reason, 

I the TTF and TTT are described in the Programmer's Reference manual. 
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SECTION 2 



TERMINAL TYPES AND LINE TYPES 



CLASSIFICATION OF COMMUNICATIONS CHANNELS 



The Multics Communication System is designed to support a wide variety of 
communications protocols and devices. For this reason, it is necessary to identify 
the particular characteristics of each channel . This identification is accomplished 
by assigning a line type and a terminal type to each channel. 



A line type defines the communications protocol used by a channel. The 
following items are aspects of the line type: 

• synchronous or asynchronous transmission 
« character size 

• error detection and recovery 

• message blocking 

• message acknowledgement 

• modem control 

Not all line types have all of the above aspects. Only synchronous line types, 
for example, are concerned with messages, which are blocks of continuously 
transmitted characters (see the discussion of synchronous protocols in Section 
3). 



A terminal type defines the operating characteristics of a terminal. These 
characteristics include: 

# character set (graphic symbols represented) 

# character code (e.g., ASCII, EBCDIC, etc.) 

# control sequences required to effect carriage movement 
and other special functions 

# number of fill characters required for carriage movement functions 

# terminal initialization sequence to clear screen, set tabs, etc. 

# line length and page length 

# character echoing modes 

The terminal type concept permits the Multics Communication System to provide a 
uniform interface for terminal input/output. This eliminates the need to embed 
terminal-speeif ic knowledge in most user and system software. 
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LINE TYPES 



The following standard line types are provided by the Multics Communication 
System : 

ASCII 

device similar to 7-bit ASCII using Bell 103-type modem protocol 

1050 

device similar to IBM Model 1050 

2741 

device similar to IBM Model 2741, with or without auto EOT inhibit 

ARDS 

device similar to Adage, Inc. Advanced Remote Display Station (ARDS) 
protocol using Bell 202S-type modem with reverse channel 

SYNC 

ASCII synchronous connections, no protocol 

G1 15 

ASCII synchronous connection, Model Level 6 remote computer interface 
(RCI) protocol 

BSC 

binary synchronous protocol 

202ETX 

device similar to GE TermiNet 1200 protocol using Bell 202S-type 
modem without reverse channel 

VIP 

device similar to Honeywell Model 7700 Visual Information Projection 
(VIP) system 
POLLED_VIP 

device similar to Honeywell Model 7760 VIP system 

X25LAP 

synchronous High-level Data Link Control (HDLC) X.25 protocol 
implementing frame level of CCITT recommendation of 1980. Used mainly 
to interface with a Value Added Network (VAN) such as TYMNET. 



It is possible for a site to create new line types not already provided by 
the Multics Communication System. Each such new line type requires the addition 
of a site-provided control tables module to the FNP software. This module must 
implement the desired communications protocol. Procedures for creating such 
modules are described in the Multics Communication System manual, Order No. AN85. 



Line Type Assignment 



The assignment of line types to channels is specified in the channel definition 
table (CDT). A complete description of the CDT is contained in Section 4 of 
this manual. The selection of a line type for a given channel must, of course, 
be consistent with the actual channel hardware. If no line type is specified 
for a channel, one of the several asynchronous line types is automatically selected. 
Therefore, line types should always be specified for synchronous channels. 



The line type of a channel can only be changed while the channel is not in 
use. Ordinary users cannot do this. In order to change a line type, an administrator 
must create a new CDT specifying a new line type for a particular channel. The 
new CDT must then be installed. The line has to be removed from the system 
using the operator command, detach, and reattached using the attach command. If 
the channel is not dialed up at this time, the new line type takes effect 
immediately. Otherwise, the new line type does not take effect until the current 
connection is terminated. 
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TERMINAL TYPES 



The terminal types provided by the Multics Communication System are defined 
in a segment called the terminal type table (TTT). This segment is generated 
from a source segment called the terminal type file (TTF) . A complete 
description of the TTF and the TTT is contained in the Programmer's Reference 
manual . 



A standard version of the TTF is provided with each system release. It 
has the pathname >tools>TTF and is copied to >udd>sa>a at site initialization 
time. This TTF can be easily modified to add new terminal types or to change 
characteristics of existing terminal types. This allows each site to develop a 
customized TTF and TTT. 

Although most users ordinarily depend on the site- instal led version of the 
TTT, it is possible for any user to substitute his own private TTT. A user can 
create a TTT in exactly the same manner as a system administrator. This affords 
users the ability to define terminal types suited to their individual 
preferences . 



Terminal Type Assignment 



An initial terminal type is assigned to a login service channel at dialup 
time in one of several ways. An initial terminal type can be specified in the 
CDT. This is commonly done for dedicated channels which are always connected to 
the same terminal. If an initial terminal type is not specified in the CDT, 
then the default type table in the TTT is used to choose a terminal type based 
on line type and baud rate. In either case, an attempt is made to read an 
answerback (if allowed by the CDT) from the terminal. If the terminal responds, 
the answerback is decoded according to answerback specifications in the TTT 
which indicate initial terminal types. 



A terminal type for slave or autocall channels may be specified in the CDT. 
If this is done, then the terminal type and the default modes for the terminal 
are set and the initial string is sent at slave channel dialup time or when an 
autocall channel is connected. If a terminal type for slave or autocall 
channels is not specified in the CDT, then the above steps are not performed. 



The initial terminal type established by the system can be changed by the 
user. The terminal_type (ttp) preaccess command can be used prior to login to 
alter the established terminal type, or the user can specify the - terminal_type 
control argument to the login command to set the terminal type accordingly. 
After login, the user may invoke the set_tty command to change his terminal 
type. The user may also change his TTT by use of the set_ttt_path command. 
Subsequent use of the set_tty command will then reference the user-selected TTT, 
All of these commands are described in the Commands manual. 
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SECTION 3 



MX)DEMS AND TE-SHI NAL -CON#E€TIONS 



A terminal or concentrator can be connected to an HMLC (or HSLA or LSLA) in | 

any of several ways, depending on the line type and the available equipment. 
The path between the FNP and the terminal is often referred to as a "communications 
link." This section describes the general types of communications links that 
are possible, and includes a list of communications equipment that may be used 
to connect a device to a Multics system. 



TYPES OF COMMUNICATIONS LINKS 



Communications links can be categorized in a variety of ways. The following 
paragraphs discuss the most important distinctions among communications links, 
namely, whether they are: asynchronous or synchronous; full duplex or half 
duplex; hardwired, private-line, or dialup. 



Asynchronous/ Synchronous 



An asynchronous link is one over which characters are transmitted singly, 
at unpredictable intervals. The individual bits of each character are transmitted 
at a fixed rate (the bit rate or baud rate of the channel), but the time between 
characters is arbitrary. To allow the hardware to identify character boundaries, 
each character is preceded by a start bit and followed by one or two stop bits. 
Each character normally includes a parity bit, which is used to check whether 
the character has been received correctly. 



On a synchronous link, characters are transmitted in continuous blocks, and 
the time between blocks is arbitrary. One or more instances of a special bit 
pattern, called a synchronization character, is transmitted at the beginning of 
each block. Parity bits may or may not be included; some kind of checksum is 
generally appended to each block to ensure correct reception of the block. The 
blocks transmitted over a given link often must contain control information in 
some specified format; see the discussion under "Communications Protocols" below. 



Intsrsctivc tcrminalo generally use aoyncaronous transmission; remote 
computers, printers, concentrators, etc., generally require a synchronous link. 
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Full Duplex/Half Duplex 



A communications link is full duplex if data can be transmitted across it 
in either direction, or both directions, without changing the physical state of 
the link. It is half duplex if the connection permits transmission in only one 
direction at a time, and requires specific action to alter the direction of 
transmission (known as "turning the line around"). Because of the number of 
telephone wires required to implement the link, full duplex links are sometimes 
)t- called "ij-wire", and half duplex links are called "2-wire." Asynchronous links 
are normally full duplex; synchronous links may be either full duplex or half 
duplex . 



Hardwired , Private Line , Dialup 



A hardwired link is one in which the terminal is connected directly to the 
FNP by means of an appropriately wired cable, i.e., a DC path. The length of 
the cable is normally limited to 50 feet, but can be longer, depending on speed, 
cable type, and hardware at each end. 



A private line is a link that utilizes a telephone-like transmission medium, 
and requires a modem at each end (see the discussion of modems below); however, 
the physical connection is reserved for use by the specific terminal-FNP link, 
and does not have to be reestablished for each use. The path may be furnished 
by the telephone company (an AC path), or be a long wire (a DC path). 



A dialup link uses a switched network, usually the public telephone system. 
Each such link must be established by dialing into the network at the start of a 
terminal session, and is closed by a hangup operation. Thus, while a hardwired 
or private-line channel appears to be dialed up immediately whenever a listen 
operation is performed by the system, a dialup channel is not available for use 
until a user has actually dialed the phone. 



Hardwired and private-line links are usually full duplex; dialup synchronous 
I links may be either half duplex or full duplex. 



It should be noted that when a channel with a login service type dials up, 
if no commands are entered within a reasonable time interval (normally two minutes) 
the answering service automatically hangs up the channel and listens to it again 
This is not desirable on a hardwired or private-line channel, since another 
dialup signal follows immediately; therefore, the hardwired attribute in the CDT 
entry for the channel instructs the answering service to leave the channel dialed 
up until the channel starts being used. This is the only effect of the hardwired 
attribute in the CDT. (See the description of the channel master file in Section! 4 
for more information about service types and channel attributes.) 



The private_line keyword used in the dataset statement in the CMF indicates 
that the channel is a private-line link, and also that it is full duplex. The 
private_line keyword is only interpreted if the dataset specified is "201C". 
Other datasets default to either private-line or dialup; see Table 3-1 (later in 
this section) for more information. 
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MODEMS 



A modem (modul ator/demodul ator ) is a device that converts a digital signal 
(received and generated by computers and terminal equipment) to an analog signal 
(suitable for transmission across telephone lines) and vice versa. A communications 
link that is not hardwired requires two modems, one cabled to the FNP and one 
cabled to the terminal, with a telephone-system connection between the two modems. 
Dataset is a frequently used synonym for modem. 



There are many different types of modems: synchronous and asynchronous; 
with and without dialing capabilities. Some can run at a variety of speeds, and 
some are restricted to a specific speed. The modems currently most common are 
those manufactured by American Telephone & Telegraph. Modems made by other 
manufacturers are available, although they generally are approximate equivalents 
of Bell modems. A specific modem model may be obtained with a variety of options. 
In most cases, the options recommended by the manufacturer should be used, but a 
few exceptions are noted in Table 3-1. 



The two modems at the ends of a communications link must be either the same 
type or compatible types and have similar or compatible options. In a few 
cases, pairs of modems operate by having one member initiate the call (at the 
terminal end) and the other respond to it (at the FNP end) ; the Bell Model II3A/II3B 
is an example of such a pair. 



Table 3-1 lists Bell modems currently usable on a Multics system, and indicates, 
for each one, the speed(s) at which it can run, whether or not it is synchronous 
or asynchronous, whether it is dialup or private-line or both, what specification 

should be given in the dataset statement of the CMF, and any other important 
information. For more detailed information on a particular modem, refer to the 
modem's technical specification, which is available from the manufacturer. 



COMMUNICATIONS PROTOCOLS 



A communications protocol is a set of conventions observed by the two ends 
of a communications link in order to exchange data in an orderly and predictable 
fashion. The specification of a protocol may include conventions for controlling 
the physical state of the link, as well as the format and sequencing of blocks 
of data. Full duplex asynchronous links do not generally use protocols; half 
duplex asynchronous links usually require fairly simple protocols to determine 
the direction of transmission at any given time. Synchronous links generally 
use more elaborate protocols to ensure that each block of data is received 
correctly and in correct sequence. 



The following are examples of asynchronous and synchronous protocols supported 
by the Multics Communications System, with the line types used to implement them 
(see Section 2 for a further discussion of line types). 



Examples of Asynchronous Protocols 



Protocol : ARDS with 202S modem with reverse channel option 

Line Type : ARDS 

Protocol ; GE TermiNet 1200 with 202S modem without reverse channel option 

Line Type: 202ETX 
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Table 3-1. Modem Descriptions 



Model No. ! 


1 Speeds 


Sync/ 1 
Async | 


Duplex 


Private/ | 
Dialup i 


CMF 

specification 


Remarks 






103A ! 


i up to 
1 300 
I bps 


async | 


full 


dialup i 


103A 
or 
none 




1 13A i 


1 up to 
1 300 
1 bps 


async | 


full 


dialup 1 


103A 
or 
none 


originates 
calls only 


113B 1 


1 up to 
I 300 
1 bps 


! async | 


full 


1 dialup 1 


103A 
or 
none 


answers calls 
only 


202C5 1 
202C6 ! 
202C10 1 


1 up to 
I 1200 
1 bps 


1 async | 


half 


dialup 1 


202C5 

or 
202C6 




202S 1 


1 up to 
! 1200 
1 bps 


1 async 


half 


1 dialup 1 


202C5 

or 
202C6 


! local carrier 
! option should 
1 be used 


202T 


1 up to 
1 1800 
i bps 


1 async 


full 


1 private 


none 
required 




212 


1 up to 
1 1200 
I bps 


1 async 
1 sync 


full 


! dialup 


none 
required 


1 high-speed 
1 option should 
1 be used 


201C 


1 2400 
1 bps 


1 sync 


half 


1 dialup 


201C 




201A 
201B 
201C 


j 2000 

' bps 


1 sync 


[ full 


i private 


201C 
private- line 




208A 


! 4800 
1 bps 


1 sync 


i full 


1 private 


208A 




208B 


1 4800 
1 bps 


1 sync 


i half 


! dialup 


208B • 




209A 


1 9600 
I bps 


1 sync 


! full 


1 private 


1 209A 


i 
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Examples of Synchronous Protocols 



Protocol : Level 6 RCI 

Line Type : G115 

Protocol : Binary synchronous (bisync) 

Line Type ; BSC 

Protocol : Honeywell polled VIP 

Line Type : POLLED VI p . . 



AUTOMATIC BAUD RATE DETECTION 



The autobaud feature of the Multics Communication System is designed to 
recognize/configure the baud rate (bits per second) of an asynchronous HMLC (or 
HSLA) channel at dialup time. The autobaud facility selects a 1200 baud rate if 
the high-speed indicator is on (pin! 12, for most modem types); otherwise it 
selects a rate of 110, 133, 150, 300, or 1200 baud based on the sampling of bit 
changes for the incoming characters, "1", "L", "CR". 



Lead Control Selection Of 1200 Baud 



If the modem connected to the FNP turns "on" pin 12 of the cable connected 
from it to the FNP, the channel is set to 1200 baud and it is then handled in 
the normal manner. The FNP modem can be set to respond to a switch on the 
terminal modem which indicates that the terminal is operating at 1200 baud. The 
operation of the channel does not appear any different to the user than if a 
strictly 1200 baud channel is dialed into (there is no requirement for the user 
to type any characters before the login banner is received). 



Bit Sampling Selects Other Bauds 



If the signal on pin 12 is "off", sampling for the bit changes of an input 
character is performed. To accomplish this, the following sequence occurs: 

1. The user establishes a connection with the host. 

2. The user types in either the letter "1" or "L" or a carriage return. 

3. The software in the FNP scans the incoming bit stream looking for bit 
changes at 300 baud. Since the sample character is known ("1", "L", 
"CR"), the changes in state of the bits ("0" or "1") indicate the 
timing necessary to transmit the bits, and therefore the baud rate of 
the channel is determined. 
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H. The channel is then handled in the normal manner. The answerback is 
checked (if required) , the initial string (if any) is sent and the 
login banner is displayed. 

5. The user types in any of the preaccess commands (MAP, etc.) if desired. 

6. The user logs into the system using "1" again for "login", enter, etc. 



Modems 



Any asynchronous HMLC channel may be configured with the autobaud feature. 
For dialup channels not using special modems, automatic baud rate detection is 
I possible only up to 1200 baud. In this range, most modems and acoustic couplers 
are able to interface with host modems. 



There are several modems that can be used on channels configured with the 
autobaud feature which make use of the pin! 12 lead change. Vadic (Model! 3^67) 
and Western Electric (Model!212A) are two manufacturers that make such modems. 
Special encoding techniques are required to handle the 1200-baud full duplex 
data over voice-grade dialup lines. For this reason, a modem of one manufacturer 
may not necessarily be able to interface to a modem of another manufacturer. 
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SECTION H 



CHANNEL MASTER FILE 



CHANNEL DEFINITION TABLE 



The channel definition table (CDT), a data base in the segment: 
>sc1 >cdt 

describes the attributes of all Datanet Front-End Network Processors (FNPs) and 
communications channels on the system. Write access on this segment is necessary 
only for the initializer; read access is necessary for users of certain metering 
commands. 



The CDT is a binary table containing numbers and pointers as well as character 
strings. Therefore, it cannot be examined or modified with standard editors. 
The display_cdt command is used to print the contents of the whole CDT or selected 
entries. The reset_cdt__meter s command resets the per channel count of dialups 
and total connect TimeT The tty_lines command lists all channels and their 
counters. When the system administrator wishes to add or delete channels, or to 
change the information about a channel in its CDT entry, he modifies the channel 
master file (CMF), converts the CMF into a new copy of the CDT with the GV_cmf 
command, and uses the install command to signal the answering service to modify 
the system's copy of the CDT. Thus, the site management can make certain changes 
in the site's configuration of terminal channels without waiting for a system 
shutdown . 



Each FN? and terminal channel in the system has a CDT entry. This includes 
not only channels used for logins, but also special terminal channels, such as 
channels used by the message coordinator for the I/O of the initializer and 
daemons, and channels describing remote stations operated by the I/O daemons. 
These channels have flags set in the CDT entry indicating the way they can be 
used . 



CHANNEL MASTER FILE 



The CMF describes all FNPs, multiplexers, and terminal channels on the 
system. It is an ASCII file, normally stored in >udd>sa>a>CMF.cmf , that can be | 
converted into a binary table, which is installed by the answering service at 
the system administrator's request. 
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Syntax of the CMF 



The CMF consists of a series of entries, one for each FNP or channel. Each 
entry consists of a series of statements that begin with a keyword and end with 
a semicolon. White space and PL/I-style comments enclosed by /* and */ may 
appear between any elements of the CMF. The last entry in the CMF must be the 
end statement. Global statements specifying defaults appear anywhere before the 
end statement; the defaults that they specify are in effect for all subsequent 
channel entries, until they are changed by subsequent global statements. Except 
for the end statement, all statements consist of the statement keyword, a colon, 
the variable field of the statement, and a semicolon. 



The entry for each FNP consists of an FNP statement, followed by statements 
describing the attributes of the FNP. Attributes not specified for an FNP are 
set from defaults supplied by the cv cmf program. 



The entry for each channel consists of a name statement naming the channel, 
which may be followed by statements describing the attributes of the channel. 
Attributes not specified for a channel are set from the defaults established by 
global statements or those supplied by the cv_cmf command. (See "CMF Default 
Statements" below.) Thus, a very simple CMF could consist of an FNP entry, a 
name statement for each channel, and an end statement, as follows: 



FNP: 
type: 

memory : 
hsla : 
name : 
name : 
end; 



A; 

DN6670; 

64; 

1; 

a .hOOO; 
a.hOOl ; 



FNP ENTRIES IN THE CMF 



A description of each statement in an FNP entry of the CMF is given below. 
FNP: <name>; 

The FNP statement is required. It specifies the tag of the FNP being 
described. Up to eight FNPs may be specified. An FNP card with the same 
name is also required in the config deck. See the Programmer's Reference 
manual for restrictions on the name of an FNP. 

type: <FNP type>; 

The type statement is optional. It specifies the type of the FNP, which 
may be either DN355, DN6600, or DN6670. DN355 and DN6600 are equivalent. 
The default is DN355. 

memory: <K-words>; 

The memory statement is optional. It specifies the size of the FNP memory 
in K (1024 words). Acceptable values are 32 through 256, in increments of 
32 (i.e., 32, 64, 96, 128, etc.) The default is 64. 

Isla: <number of lslas>; 

The Isla statement is optional. It specifies the number of LSLAs configured 
on this FNP ( DN6600/DN355 only). The number may be zero through six; the 
default is zero. 

hsla: <number of hslas>; 

The hsla statement is optional. It specifies the number of HSLAs configured 
on this FNP. The number may be zero through three; the default is zero. 
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image: <path>; 

The image statement is optional. It specifies the pathname of the FNP core 
image to be used for this FNP. The default is >system_control_1 >mcs . Each 
FNP may have a different core image depending on its configuration and 
supported line types. The path argument should specify a segment that is 
on the root logical volume to ensure that the FNP can be reloaded without 
having to worry about demounted volumes. (The FNP cannot be reloaded if 
path is on a demounted volume.) 

service: <active or inactive>; 

The service statement is optional. If specified, the variable field must 

be either active or inacti.ve., An active FNP is- loaded an4 used b-y the 

system. An inactive FNP is not automatically loaded. However, it can be 
loaded by operator com.mand or made active by installation of a new CDT. 
(If an FNP is missing from the CMF at answering service startup time, 
rather than being included with a service type of inactive, it cannot be 
used during the current Multics bootload. The default is active. See 
"Changing Channel Configuration," below.) 



CHANNEL ENTRIES IN THE CMF 



A description of each statement in a channel entry of the CMF is given 
below. 

name: <channel name>; 

The name statement is required. It specifies a unique channel name for the 
channel and can be up to 32 characters long. FNP-type channel names are 
divided into components separated by periods, with each component 
representing a level of multiplexing. A complete description of channel 
naming conventions appears in the Programmer's Reference manual. 

name: <channel name 1>-<channel name 2>; 

A pair of channel names can be given in the name statement. The first N 
characters of the two names must be identical, where N is that portion of 
the names up to the digits representing the first and last subchannel 
numbers (the subchannel number in the second name must be greater than that 
in the first name). The effect of this form of the name statement is to 
specify a group of adjacent channels having identical characteristics. 
Their names are formed by starting with the first name, increasing the 
subchannel number by 1 to form each name, and ending with the second name. 
The number of channels in the group is equal to one plus the difference 
between the two subchannel numbers. 



For example: the name statement a . h 1 00-a . h220 specifies a group of 
successive channel names, the first of which is a.hlOO, the second, a.hlOl, 
the third, a.h102, etc., up to a.h220. Likewise, the name statement 
b.h203.prt 1-b.h203prt8 specifies a group of eight channel names, the first 
of which is b.h203.prt1, the second, b.h203prt2, the third, b.h203.prt3, 
etc., up to b.h203.prt8. 

generic_destination: <"string"> ; 

The generlG_dest inaticn statement is cpticnal snd applies only to the slave 
and autocall service types. The string may be any site-specific value 
(e.g., tymnet, modem, protocol_converter_box) that does not resemble a 
channel name. If included in the CMF entry, the string is used to match 
the channel specifier used in a dial_out or privileged_attach operation. 
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baud: <bauci_rate>; 

The baud statement is optional. It specifies the baud rate of the channel. 
The baud rate must be compatible with the FNP line adapter type and must be 
chosen from the following list: 



0 600 7200 

110 1200 9600 

133 1800 19200 

150 2400 40800 

300 4800 50000 

72000 



The channel is assumed synchronous only if a synchronous line type is also 
specified. Zero and none are equivalent and may only be used for network 
channels, which are not attached through an FNP. The auto keyword requests 
automatic baud rate detection at dlalup time for HSLA channels (see the 
discussion of automatic baud rate detection in Section 3)« Baud rates 
higher than 19200 are valid only for synchronous channels. 



NOTE: At speeds of 4800 baud and below, no more than 960 characters are 
sent to the FNP at a time. 

The baud rate of a synchronous channel is not controlled by software. The 
baud statement for a synchronous channel simply informs the system of the 
speed of the hardware connection. The correct baud rate should be 
specified, however, so that the system can choose the optimal buffer size 
for the given rate. 

attributes: <attr1, attr2, ... attrN>; 

The attributes statement is optional. This statement applies only to login 
service channels. When this statement is used, the global attributes are 
overridden for this channel. If no attributes statement is specified, the 
global attributes are used. The " character is used to negate the 
specified attribute. The following attributes may be specified: 

audit, ''audit 

if enabled, access errors on the channel are audited. 

check_acs, ''check_acs 

if enabled, access to the channel is controlled by the access 
control segment >sc 1 >rcp>CHANNEL-NAME.acs. For details on the 
ACS, see "Access Control Segments" in the MAM System. 

check_answerback , ''check_answerback 

if enabled, specifies that the answerback 
channel is to be checked against the one 
answerback statement (see below). 

dont_read_answerback, *dont_read_answerback 

if enabled, specifies that no attempt is to be made to read the 
answerback of the channel. 

hardwired, ''hardwired 

if enabled, specifies that the channel is directly wired, not 
connected through a switching system. 

none 

if enabled, specifies that all of the "*" values of the 
attributes listed above are assigned. 

set_modes, ''set_modes 

if enabled, specifies that the modes associated with the 
terminal type of the channel are to be set when the channel 
dials up. 



returned by the 
supplied in the 
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access_class : <"authorization"> ; 

The access_class statement is optional. If specified, it must be 
followed by a valid authorization string, enclosed in quotes. The 
specified authorization is the maximum authorization for any login 
over the channel. See the convert_authorization_ subroutine in the 
Subroutines for an explanation of valid authorization strings. 

answerback: <string>; 

The ansiverback statement is optional. This statement applies only to 
login service channels. If specified, it must have as a variable 
field a four-character string that is the expected answerback for the 

channel. Th.e star' convention is. allowed. If the value Is. ..null, then. 

no answerback check is made. Otherwise, the answerback code from the 
terminal is matched with the specified field; if they disagree, a 
message is printed to the user and to the operator, and the channel is 
hung up. 

terminal_type : <terminal type>; 

The terminal_type statement is optional. If specified, its variable 
field must contain one of the terminal types defined in the terminal 
type table (described in the Programmer's Reference manual); specified 
terminal types are checked against the current TTT when the CDT is 
installed . 



The names of the possible terminal types can be ascertained by using 
the print_terminal_types command (described in the Commands manual). 
These names may be entered in uppercase or lowercase. The terminal 
type specified is set before any input or output is done to the 
terminal; thus, this statement overrides the default terminal type 
(which is based on the line type and baud rate). For example, if a 
site has some IBM Model 2741s that are EBCDIC and some that are 
Correspondence, the terminal_type statement may be used to determine 
whether the greeting message is printed in EBCDIC or Correspondence. 
The terffiinal_type statement does not force the terfflinal to remain the 
same type; it merely specifies the initial type. Thus, the answerback 
identifier, the -terminal_type login control argument, and process 
requests may override the terminal_type statement. 

~~ The line_type statement is optional. If specified, its line type 
field must contain one of the following line types: 



none unspecified (select protocol at dialup time) 

ASCII terminals: ASCII, TN300, TTY33, TTY37, TTY38 

1050 terminal: 1050 

2741 terminals: 2741, CORR2741 

ARDS 202S with ARDS line turnaround (reverse channel) 

Sync synchronous line, no protocol 

G115 remote computer interface, synchronous (CRTS) 

BSC binary synchronous communications 

202ETX 202S with ETX line turnaround (no reverse channel) 

VIP Honeywell VIP 7700, single station 

POLLED_VIP Honeywell VIP 7760 

X25LAP HDLC X.25 frame level 

A SYNC 1 

ASYNC2 optional site-defined asynchronous line types 
ASYNC3 

SYNC1 

SYNC2 optional site-defined synchronous line types 
SYNC3 
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The line type specified is passed to the terminal control software 
before the channel is enabled for listening, in order to set the line 
protocol to be used for handling communications on the channel. If no 
line_type statement is specified, the terminal control software is 
capable of determining (for LSLA and asynchronous HSLA channels) 
whether the protocol used should be one of: 

2741 133 baud default 

1050 133 baud alternate, if answerback indicates 

ASCII default for all other speeds 

If an ARDS terminal is to be used, a line_type statement must be 
specified (i.e., line_type: ARDS;). 

dataset: <name>, <attr>j 

The dataset statement is optional. It identifies the generic type of 
dataset/modem being used on the channel. If specified, the name field 
must be chosen from the following list of Bell modem names, although 
any modem that is similar may be used. 

103A 208A 
20 IC 208b 
202C5 209A 
202C6 

The attribute may be private_line to indicate that the modem is being 
used on a 4-wire circuit (see Section 3 for more information). 

charge: <chargename or none>; 

The charge statement is optional. If specified, its variable field 
must contain a charge name listed in the device prices array in the 
installation_parms segment (see Section 4 in the MAM System), or be 
"none." The charge type selects the per-hour surcharge for use of the 
channel. 

service: <service type>; 

The service statement is optional. If specified, its variable field 
must be one of the following service types: 

login 
mc 

slave 
autocall 
inactive 
multiplexer 

The service type determines whether the channel can be used for normal 
logins or is under control of some special software. The slave 
service is used only for special channels attached by the I/O daemons 
for bulk data input/output or other special subsystems. The mc 
service is specified for all message coordinator channels. The 
autocall service indicates that the channel is used to dial out using 
an automatic call unit. The inactive service indicates that the 
channel exists but is currently not to be used. A channel installed 
as inactive can be changed only through installation of a new CDT. A 
channel rendered inactive because of an error condition or operator 
command (remove) can be changed either through the operator attach 
command or installation of a new CDT. The multiplexer service type is 
used for a multiplexer channel (see the discussion of multiplexers in 
Section 1). If a service type of multiplexer is specified, the 
multiplexer_type statement (see below) must be provided. 

Access Control Segments (ACSs) specify access to the slave and 
autocall lines. Access to login lines may be similarly 
controlled--see the description of the attributes statement above. 
See also "Access Control Segments" in the MAM System. 

A service type of slave must be specified for every channel that an 
I/O daemon driver directly attaches, and the names of such channels 
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must be specified in the I/O daemon tables, >ddd>idd>iod_tables . 
Channels that are to be dialed to a daemon driver must be given a 
service type of login in the CMF, and dial identifiers must be 
specified in the I/O daemon tables. (In order to use a particular 
registered dial identifier, a user must have rw access to the ACS. 
See Section 7, "Registered Dial Identifier," in the MAM System for 
more information.) 

The default service type is login — meaning that the normal logins are 
allowed . 

multiplexer^type : <type>, <active or inactive>; 

The multiplexer_type statement is required for channels with a service 
type of multiplexer and is invalid for other channels. If it is 

specified, the variable field must be ibm3270, vip7760, hasp, sty, or 
x25. It indicates the type of multiplexer to be connected to the 
channel. The multiplexer is initialized as soon as its parent 
multiplexer initializes if this statement includes the active key. 
The multiplexer is not initialized until the load_mpx operator command 
is used if this statement includes the inactive key. The default is 
active. 

comment: <"string">; 

The comment statement is optional. If its variable field contains any 
blanks or punctuation, it must be enclosed in quotes. The variable 
field is saved in the CDT entry (up to 48 characters). The comment 
field may be used to identify the modem and telephone line connected 
to a channel. The comment is printed by the tty_lines command and by 
various answering-service programs that print error messages about the 
channel . 

initial_Gommand : <"initializer request">; 

The init ial_command statement is optional. This statement applies 
only to login service channels. If it is specified, the variable 
field must be a valid initializer command (e.g., login, dial) line, 
enclosed in quotes. Whenever the channel dials up, the initial 
command is executed before the first line is read from the terminal. 



CMF Default Statements 



Control statements that begin with a capital letter are global statements. 
Global statements exist for each of the statements that specify attributes. If 
no global statements are given in a CMF, the following set of defaults is 
assumed : 



Attributes : 
Access_class : 
Answerback : 
Baud : 

Generic_destination; 

Line_type : 

Terminal_type : 

Charge: 

Service: 

Comment : 

Initial command: 



none ; 

system_low; 

«! n . 

306; 

fi ti . 

> 

none ; 
none; 
none ; 
login; 
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GLOBAL STATEMENTS APPLICABLE TO ALL FNPS 



The following additional global statements are used to set system-wide 
parameters : 

FNP_required_up_time: <number of minutes>; 

The FNP_required_up_time statement is optional. It sets the minimum 
acceptable time between failures for all FNPs. If an FNP crashes after 
being up for less than the specified number of minutes, twice in 
succession, then it is not reloaded automatically. The default is five 
minutes. A value of zero disables automatic reloading of FNPs. 

Spare_channel_count : <number of spare channels>; 

The Spare_channel_count statement is optional. It specifies the number of 
channels the site expects to add to the CMF between system initializations 
(without rebooting Multics). In other words, if Spare_channel_count is 20, 
and the CDT in use at system initialization time specifies 100 channels, no 
more than 120 channels can be configured during that session. The LCT 
(logical channel table) is allocated in tty_buf with the number of entries 
equal to the number of channels in the CDT plus the number specified in 
this statement. An FNP initialization error occurs if the number of new 
channels being added exceeds the spare channel count and an FNP load occurs 
before the system is reinitialized. The default is 10. 



Changing Channel Configuration 



The channel configuration and the characteristics of existing channels can 
be changed at any time by installing a CDT containing the new information. 
Section 5 describes the procedures for making these changes and discusses their 
implications. 



The parameters that are changed at the next Multics bootload are actually 
set during answering service initialization, when either the startup or multics 
command is given. If necessary, changes to these parameters can be made by 
copying a new CDT into >sc1 in the initializer process in admin mode, before the 
answering service is started. However, use of this method to replace the CDT 
destroys the channel usage statistics kept in the CDT entries. The preferred 
way to make a channel configuration change take effect immediately is to issue 
the initializer command, multics, and then with the initializer process in admin 
mode, modify the CMF, compile it, install the CDT using the install command 
(which preserves channel usage statistics), and then shut down and reboot 
Multics . 



SAMPLE CHANNEL MASTER FILE 



/* Sample Channel Master File */ 

Service: login; 
Charge: none; 
Terminal_type : none; 
Line_type: none; 
Attributes: none; 
Baud: 300; 

Access_class: "system_high" ; 
FNP_required_up_time: 2; 

FNP: A; 

type: DN6670; 
memory: 64; 
hsla: 1; 
image: mcs; 
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name: a.hOOO; 
baud: 9600; 

terminal_type: VIP7801; 

attrributes: hardwired, dont_read answerback; 

initial_command : "modes echoplex, '^tabs,tabecho,crecho, If echo" ; 
comment: "1200 baud, hsla 0, subchn 0"; 

/^temporarily disconnected, so comment it out: 
name: a.hOOl; 
baud: 1200; 
charge: caa; 
terrainal_type: ASCII; 

cbmment":~"T20^^^ hsla 0, subchn 1, x3T9, vadic"; 

end comment out */ 

name: a.h002; 
baud: auto; 

comment: "auto baud, hsla 0, subchn 2, x3l6"; 

name: a.hOOS; 

comment: "300 baud, hsla 0, subchn 3, x324"; 

Baud: 4800; 
name: a.h012; 

service: slave; 

line_type: BSC; 

dataset: 208A; 

comment: "hsla 0, subchn 12, BSC"; 

name: a.h013; 

service: slave; 
line_type: BSC; 

dataset: 208A; 

comment: "hsla 0, subchn 13, BSC"; 

name: a.hOl4; 
baud: 4800; 
line_type: BSC; 
service: multiplexer; 
multiplexer_type : hasp; 
terminal_type : IMFT_HASP_WORKSTATION ; 
comment: "HASP multiplexer used for file transfer"; 

name: a.h0l4.opr; 
service: slave; 

comment: "IMFT HASP daemon - operator control stream."; 

name: a.h0l4,rdr1-a.hOl4.rdr8; 

service: slave; 

comment : "IMFT HASP daemon I/O stream."; 

name: a.hOl4.pun1-a.h014.pun4; 
service: slave; 

comment : "IMFT HASP daemon I/O stream."; 

name: a.hOl4.prt 1-a.hOl4.prt4; 
service: slave; 

comment : "IMFT HASP daemon I/O stream."; 

name: a.hOI?; 
charge: caa; 
terminal_type : ASCII; 
attributes: hardwired; 

comment: "4800 baud, hsla 0, subchn 17, hw Delta 4000"; 

name: a.h0l8; 
baud: 1200; 
charge: caa; 
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terminal_type : ASCII; 

comment: "1200 baud, hsla 0, subchn 1, x319, vadic"; 

name: a.h020; 
baud: 2400; 
service: multiplexer; 
multiplexer_type x25; 
line_type: X25LAP; 
terminal_type: X25_TYMNET; 

comment: "TYMNET voice-grade HDLC X25 link."; 

name: a.h020. 001 -a.h020. 028; 
initial_command : echo; 

comment: "TYMNET X.25 login subchannels"; 

name: a.h020. 029-a.h020. 032; 
service: autocall; 
line_type: X25LAP; 

comment: "TYMNET X.25 autocall subchannels."; 

name: a.hOBO; 

line_type: POLLED_VIP; 

baud: 4800; 

service: multiplexer; 

multiplexer type: vip7760; 

comment: "MB"00 VIP7760 polled controller"; 

terminal_type : VIP7760_CONTROLLER ; 

name: a.hOBO.dOl; 

terminal_type: VIP7760; 

comment: "Station 01 on polled VIP"; 

name: a.h030.d02; 

terminal_type: VIP7760; 

comment: "Station 02 on polled VIP"; 

end ; 
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SECTION 5 



MODIFYING COMMUNICATIONS CHANNELS 



This section describes the recommended procedures for modifying the 
configuration of communications channels on the Multics system. In particular, 
it describes the procedures used to add a channel, delete a channel, or change 
the characteristics or status of an existing channel. 



In general, one or two major steps are involved in modifying the channel 
configuration. The first step is changing the CDT, which can be done in any 
sufficiently privileged process, as follows: 



1. Use a text editor to make the necessary changes to the CMF; 

2. Use the cv_cmf command to create a CDT from the new CMF (in >udd>sa>a) | 

3. Use the install command to install the new CDT. 



The syntax of the CMF is described in Section , the cv cmf command is 
described in Section 7, and the install command is described iii RAM System. 



The second major step, which is not necessary in all cases, is reloading 
(or reinitializing) the multiplexer of which the channel being changed is a 
subchannel. In the case of physical channels, of course, this is an FNP (see 
the discussion of multiplexers and subchannels in Section 1). This is done by 
means of the load_mpx initializer command, described in the MOH, and requires 
the use of the operator's console, a terminal dialed to the initializer, or the 
send_admin_command command (described in the MAM System) . It is suggested that 
the -GheGk~control argument to the load_mpx command be used to obtain information 
about possible inconsistencies in the configuration. 



Loading a multiplexer while one or more of its channels is in use is not 
recommended unless all such users are warned and given a chance to log out. In 
any case, the load mpx command, unless given the -force control argument, refuses 
to proceed if anyoTthe multiplexer's channels are in use. The stop mbx initializer 
command can be used to prevent any idle channels from being "Bialed up to a 
multiplexer scheduled for reloading. 



ADDING CHANNELS 



To add a channel to the system, simply add the description of the channel 
to the CMF, compile and install the new CDT, and, when appropriate, reload the 
immediately superior multiplexer (e.g., if adding channel a.h007, reload FNP a). 
Once this has been done, and the appropriate physical connection has been made, 
the channel is ready for use. Note that the reloading of the multiplexer is not 
necessary if the channel was configured the last time the multiplexer was loaded; 
i.e., if two new CDTs have been installed since the last load of the multiplexer, 
one deleting the channel and the other restoring it, the channel is then ready 
for immediate use without reloading the multiplexer. 
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DELETING CHANNELS 



To delete a channel from the system, delete (edit) its entry from the CMF, 
and compile and install the new CDT. If the channel is in use at the time, the 
installation of the CDT causes it to be hung up and any associated user process 
to be destroyed. The channel is then made unusable. Note that the multiplexer 
does not have to be reloaded to accomplish this effect; in fact, if it becomes 
desirable to restore the channel later, this can be done simply by adding it to 
the CDT as described above, provided that the multiplexer has not been reloaded 
in the meantime. 



CHANGING THE STATUS OF A CHANNEL 



It may be desirable at various times to change the status or characteristics 
of one or more channels in any of several ways. Changes in the physical configuration 
may necessitate changing the line type, baud rate, or other attributes of a 
channel; the site may wish to change the way a channel is used by changing its 
service type; or it may be necessary to make a channel temporarily unusable. 
These changes can be effected by changes to the CDT and/or the use of initializer 
commands; some of them, to take effect, require reloading of a multiplexer. The 
most common types of changes, and the procedures used to accomplish them, are 
described below. 



Changing Channel Attributes 



In general, it is possible to change those attributes of a channel that are 
specified in the CMF by modifying the CMF entry and compiling and installing the 
new CDT. The changes thus specified do not, in general, take effect immediately 
on a channel that is already dialed up, but rather are saved until some change 
occurs in the state of the channel. The change of state may actually take 
effect at the next hangup, the next dialup, or the next load of the multiplexer. 
Table 5-1 shows, for various channel attributes, when a change in the attribute 
takes effect, depending on whether the channel is currently in use. Some attributes 
should never be changed on an active channel: the access class attribute (shown 
below in Table 5-1) and those entries in Table 5-2 tffat say "immediate" or 
"remove" . 



Attaching , Detaching , and Removing Channels 



The initializer commands attach, detach, and remove (described in the MOH) 
are used to change the state of a channel as perceived by the system. The 
following paragraphs describe their effects and the circumstances under which 
they should be used. 



attach 



The attach command puts a previously inactive channel into a state where it 
can accept dialups. The channel might be inactive as the result of a detach or 
remove command (see below) , or through some error condition which rendered it 
inactive. However, a channel defined at CDT installation time with a service 
type of inactive can be placed in another state only through a subsequent CDT 
installation . 



5-2 



CC75-01 



Table 5-1. Changing Channel Attributes 



Attribute Channel in Use Channel Not in Use 



access__class 


dialup (see 


Note below) 


immediately 




baud 


multiplexer 


load 


multiplexer 


load 


answerback 


dialup 


- 


dialup 




line_type 


hangup 




immediately 




dataset 


multiplexer 


load 


multiplexer 


load 


terminal_type 


dialup 




dialup 




initial__command 


dialup 




dialup 




charge 


dialup 




dialup 




set modes 


dialup 




dialup 




audit 


dialup 




dialup 




hardwired 


hangup 




dialup 




check_answerback 


dialup 




dialup 




dont__read_answerback 


dialup 




dialup 




multiplexer type 


multiplexer 


load 


multiplexer 


load 



NOTE : If the new access_class is lower than the authorization of the process 



detach 



The detach command renders a channel unusable until it is reattached or its 
multiplexer is reloaded. It can be used to disable a channel temporarily. If a 
user is logged in over the channel, the user is bumped as a result of the detach 
command. 



remove 



The remove command has the same effect as the detach command r The principal 
difference is that it forcibly hangs up the channel and detaches it from any 
user process, whereas the detach command buraps the user by signalling the answering 
service. The remove command can thus be used in cases when the channel or its 
associated data bases are in an inconsistent state, and a detach or bump operation 
has failed to complete properly. Certain changes in service type cause a channel 
to be automatically removed, as explained below. A removed channel, like a 
detached one, is restored by the attach command, or when the multiplexer is next 
loaded . 
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SERVICE TYPES 



If a channel presently being used or available for one type of service 
(e.g., user login) is to be changed to a different type (e.g., autocall), its 
CMF entry must be modified and a new CDT compiled and installed. The change of 
service type may not take effect immediately, particularly if the channel is in 
use. In some cases, the change does not take effect until either the 
multiplexer is reloaded or the channel is detached and attached; in other cases, 
the installation of the CDT automatically removes the channel, and the new 
service type goes into effect only when it is reattached. Table 5-2 shows, for 
each combination of old and new service type, when the change actually takes 
effect. A notation of "attach" indicates that the channel must be detached and 
reattached; a notation of "remove" indicates that the channel is automatically 
removed, and must be attached (by operator command, or a subsequent CDT 
installation or answering service startup) before it can be used with its new 
service type. Reloading a multiplexer implicitly attaches all of its 
subchannels whose service types are not "inactive." 



Table 5-2. Changing Service Types 



Service 

Type 
OldXNew 


1 login 


MC 


1 slave 


1 autocall 


1 multiplexer' 


inactive 


login 




remove 


I remove 


1 hangup( 1 ) 


i remove(2) ! 


remove 


MC 


i attach 




! attach 


1 attach 


1 attach(2) i 


hangup( 1 ) 


slave 


i immediate I 


attach 




! immediate 


1 remove(2) i 


hangup( 1 ) 


autocall 


i hangupC 1 ) 


remove 


1 remove 




1 remove(2) ! 


remove 


multiplexer 


1 remove 


remove 


j remove 


j remove 




remove 


inactive 


'■immediate I 


attach 


i attach 


1 immediate 


1 attache 2) 1 





(1) If the channel is not dialed up, the change takes effect immediately. 

(2) The multiplexer channel cannot be used until its parent multiplexer 
(generally an FNP) is reloaded. 



12/83 



5-4 



CC75-01B 



FNP AND MULTIPLEXER CONFIGURATION 



Multiplexers (including FNPs) can be added, deleted, and have their states 
changed in ways somewhat analogous to those described above for ordinary channels . 
Adding a multiplexer is like adding any other channel; the channel does not 
become usable until its parent multiplexer is loaded. In the case of an FNP, 
there must be a corresponding FNP card in the config deck (see the description 
of the config deck in the MOH). In other words, if a new CDT is installed with 
an additional FNP, and no corresponding FNP card appears in the config deck, 
that FNP cannot be loaded. 



Deleting a multiplexer channel implicitly deletes all its subchannels. (In 
fact, a CMF specifying subchannels of an undefined multiplexer channel is in 
error and cannot be compiled) . Changing the service type of an existing 
non-multiplexed channel to "multiplexer" is equivalent to adding a new multiplexer 
channel. As indicated in Table 5-2, such a channel is generally removed when 
the new CDT is installed, and cannot be used as a multiplexer until its parent 
multiplexer is next loaded. 



The stop_mpx initializer command (described in the MOH) causes the multiplexer 
to refuse to accept dialups on its subchannels without affecting any subchannels 
that are already dialed up. It can be used while the multiplexer is running or 
before loading it; in the latter case, the multiplexer can be initialized without 
accepting dialups from any subchannels. In either case, the effect of the stop mpx 
command can be reversed by using the start mpx command. 



If a multiplexer disconnects (or, in the case of an FNP, crashes), all its 
subchannels are automatically hung up. They are not listened to again until the 
multiplexer is reloaded (if any of the subchannels is itself a multiplexer, the 
hangup is of course propagated to its subchannels, and so on). The reload is 
usually performed automatically by the initializer. If, however, a multiplexer 
crashes repeatedly in a short interval (namely, the number of minutes specified 
for the FNP required up time statement in the CMF), a message such as: 

FNP a is in apparent crash loop and will not be reloaded 

is printed at the initializer terminal, and automatic reloading is discontinued. 
At this point, it is advisable to consult the programming staff. Once whatever 
is wrong has been fixed, the multiplexer can be reloaded manually using the 
load mpx command . 
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FNP Crash Notification 



It is possible to set up at a given installation an exec_coin to be invoked 
automatically whenever the FNP crashes, which informs the appropriate personnel 
of the subsequent automatic dump. The exec_com might: 

• send mail as notification of the existence of the dump 

• automatically format and dprint the dump 

• automatically backup to an older core image 



The administrator creates an exec_com named fnp_crash_notif y .ec in the 
directory >sc1. The exec_com may contain, for example: 

&command_^line off 

sm Prog sm [string "FNP" &1 "crashed at" [date time] "running" &2] 



Then, after an FNP dump is taken, the answering service looks for the 
existence of >sc 1 >fnp_crash_notif y .ec . If this segment is found, it is invoked 
as follows: 

ec fnp crash notify fnp tag core image path dump path 



There is no default exec com; each installation must prepare its own. 
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SECTION 6 



FNP CORE IMAGES 



Programs that run in the FNP are loaded from a "core image" that resides in 
the Multics storage hierarchy. The pathname of this core image is specified in 
the CDT, as explained in Section U. 



MODIFYING FNP CORE IMAGES 



It may be desirable, on occasion, to modify this core image in order to 
make use of improvements or bug fixes to the software; to add a module in order 
to run a new line type; to delete unneeded programs in order to make more buffer 
space available in the FNP; or to change the maximum number of LSLAs or HSLAs 
that may be configured. Any such change does not take effect until the FNP is 
next loaded. 



The system administrator does not usually have to change the contents of an 
FNP module; if he does, however, he should edit the source segment, which is 
named MODULE. map355, where MODULE is the name of the module. The map355 command 
(described in Section 7) is then used to produce an object segment named MODULE.ob jdk , 
which is used in the next step (binding) . Before binding can be performed , 
however, object segments in the FNP that are unchanged must be extracted from 
the object archive (see the MPM Comm.ands) into a directory in the search list 
(the default is the working directory). 



In order to prepare a new core image, the bind fnp command must be used. 
If the configuration of HSLAs or LSLAs is being changed, memory size is being 
changed, or modules are being added or deleted, the bindfile must be modified. 
The bindfile is a segment named IMAGE. bind fnp, where IMAGE is the name of the 
core image to be generated (usually "mcs").~ The output of the bind fnp command 
is a core image segment named IMAGE. The bind fnp command is described in 
Section 7. 



USING FNP CORE IMAGE 



To make use of the cere image thus created, either copy it to the place in 
the storage hierarchy described by the image pathname in the CDT, or change the 
specification of the core image pathname in the CMF, convert it, and install the 
resulting CDT. The next time the FNP is loaded (either automatically or by 
means of the load mpx operator command), the new core image is used. 
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REQUIRED MODULES 



The Multics Communication System requires that a number of modules be present 
in the FNP core image. These modules form the basic software to support the 
activities of the channels attached to the FNP. The modules are: 

control_tables 

dia_man 

interpreter 

scheduler 

utilities 

init 



Note that the init module is required in the core image but that after it is 
finished initializing, its space in the FNP memory is released for use as input 
or output buffers. 



OPTIONAL MODULES 



All other modules are optionally configured depending on site requirements. 
Some of these modules are required because of the line type statement in the 
CMF. The following table indicates which module is required in the core image 
when a channel is configured on an FNP with a line type in the CMF: 



line type in CMF 



ASCII 

1050 

2741 

ARDS 

Sync 

G115 

BSC 

202ETX 
VIP 

POLLED VIP 
X25LAP~ 



FNP module 



control_tables 
control_tables 
control tables 
ards_ tables 
control tables 
g1 15_ta^les 
bsc_tables 
t202 tables 
vip "Uables 
polled vip_tables 
x25 ta"5les 



The autobaud tables module is required when the baud rate of a channel is 
specified as "auto". 



The lsla_man module need only be present if the number of LSLAs is not 
zero. This module should not be configured in the core image for a DN6670 FNP. 
If the lsla_Kian module is not configured, the module keyword (along with the 
type and size keywords) describing the Isla man module must not be in the bindfile. 



The hsla_man module is an optional module for DN355 or DN6600 FNP types if 
HSLA hardware is configured. This module must be in the bindfile for a DN6670 
FNP. If the hsla__man module is not configured, the module, type and size keywords 
describing this module must not be in the bindfile. 
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The trace module is optional and if left out, the module keyword with its 
size and mask must also be removed. 



The acu_tables module is required in the FNP core image if one of its 
channels has the service type of "autocall" in the CDT. 



The hasp_tables module is required with bsc_tables if a HASP multiplexer 
channel is configured on the FNP. The line type of this channel is BSC in the 
CDT, causing bsc_tables to take control of the channel when the FNP is told to 
listen to it. As the HASP muLtiplexer is loading, it notifies bsc_tables to use 
haspTtables to fiel p ""wi"tli the IThe "pr otoc 

The breakpoint_man module is only required if the system maintenance 
personnel want to set breakpoints in a control tables module. This mechanism is 
only defined to operate on code that is interpreted by the interpreter module 
and constructed of op_blocks. See the Multics Communications System manual for 
more details. 



The ibm3270__tables module is required with the bsc_tables module to service 
a channel using IBM3270 protocol. The line type of this channel is BSC in the 
CDT causing bsc_tables to take control of the channel when the FNP is told to 
listen to it. The ibm3270 I/O module in the control system indicates to 
bsc_tables through a line conT^rol order that it is to use the ibm3270_tables to 
help with the line protocol. Refer to the Subroutines manual for further 
information . 



The console_man module is only required if the console keyword parameter is 

yes. 



The meters module is required if the meter keyword parameter is yes or 
omitted . 



The pr inter_trace module is only required if printer tracing is desired on a 
DN355 or DN6632 with a printer configured. This feature is not supported on a 
DN6670. 



The ic_sampler module is only required if the ic_sample request to the 
debug_fnp command is to be used. Refer to the debug_fnp command description in 
the Multics Communications System manual for further information. 



There is no macros module. The macros .map355 is the source that creates 
the 355_niacros library that is used by the map355 command to assemble all the 
modules that execute in the FNP. The macros .map355 source is also used in 
creating a data base utilized by the debug_fnp command to reference values in 
the FNP by name rather than by absolute location. 



A GCOS job named macros_asm is used to produce the 355_macros library. If 
it is necessary to generate a new macro library, this job should be run in a 
working directory that contains the macros .map355 source, using a command of the 
form : 

gcos >ldd>mcs>info>macros_asm -truncate {other -control_args} 

where other -control_args may include, for example, -list and -lower_case to 
produce an ASCII list segment. Refer to the Multics GCOS Environment Simulator 
manual, Order No. AN05, for more information. 
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The gicb module is kept separate in a suitable form for loading into the 
FNP in the directory >system_library_unbundled . This is the first executable 
code loaded into the FNP which loads the core image into the FNP. For further 
information, refer to the Multics Communications System manual. 



THE BINDFILE 



The bindfile is a segment containing symbolic instructions that control the 
operation of the bind_fnp command. Its entryname ends with a suffix of bind_fnp. 

The symbolic instructions of the bindfile have their own syntax that allows 
for statements consisting of a keyword followed by zero or more parameters, and 
ending with a statement delimiter. Each keyword designates a certain action to 
be undertaken by the bind_fnp command pertaining to parameters following the 
keyword . 



Following is a list of the delimiters used: 



keyword delimiter. It is used to identify a keyword followed by 
one or more parameters. A keyword that is followed by no parameters 
is delimited by a statement delimiter. 



statement delimiter. 



parameter delimiter (the last parameter is delimited by a statement 
delimiter) . 



begin comment. 



end comment. 



Bindfile Key Words 



hsla 



Isla 



the parameter is the maximum number of high speed line adapters (HSLA) 
that this core image supports. 

the parameter is the maximum number of low speed line adapters (LSLA) 
that this core image supports. 



memory 

the parameter is the amount of memory available on the FNP expressed 
in units of 1024 l8-bit words. 

console 

the parameter can be: 

yes console can be configured, 
no console cannot be configured. 



printer 

the parameter can be: 

yes printer can be configured, 
no printer cannot be configured 
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meter 

the parameter can be: 

yes metering is enabled, 
no metering is disabled. 

order 

the parameters are a list of FNP object segments in the order they are 
to be loaded. The suffix objdk is assumed for all object segments. 
The last segment specified must be init. 

entry 

the parameter specifies the name of the entry at which execution is to 
begin after the segment is loaded into the FNP. Unless the site is 
using a changed version of the init module, the entry must be istart, 

version 

the parameter is a string of up to four characters that is stored in 
the core image as its version identifier. This string is printed when 
the FNP is loaded, and is also printed by the tty meters command. 

module 

the parameter specifies the name of the FNP object segment that will 
be described by the following keywords. 

type 

the parameter specifies the type of FNP object segment. It can be one 
of the following: hsla, Isla or trace. 

size 

the parameter is the number of 18-bit words required for table space. 
The use of the size statement depends on the type specified for this 
module. If the type is trace, then size represents the size of the 
trace table. If the type is hsla or Isla, then the size represents 
the size of each HSLA table (or LSLA table). If a site is configuring 
less than the maximum number of LSLAs or HSLAs , the bind fnp command 
will remove unused table space from the end of the module. 

mask 

the parameter is a 6-digit octal number that specifies the modules to 
be traced. Only the six high-order bits (two digits) of this number 
are interpreted; each bit corresponds to one module. If the bit is 
"1"b, the corresponding module is traced. The correspondence between 
bits and modules is as follows: 



bit 


octal representation 


module 


0 


ilOXXXX 


scheduler 


1 


20XXXX 


dia man 


2 


10XXXX 


interpreter 


3 


OilXXXX 


utilities 




02XXXX 


Isla man 


5 


01XXXX 


hsla man 



This keyword can only be used if a trace type was also specified. 

end ; 

specifies the end of information to be processed from the bindfile. 
It must be present at the end of the bindfile. 
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/* Bindfile for Multics Communications System 



/* FNP configuration info */ 

version: 5.0; 

hsla: 3; 

Isla: 0; 

memory: 6M; 

console: no; 

meter: yes; 

printer: no; 



/* module load list */ 

order: scheduler, 

interpreter , 
control_tables , 
dia_man , 
hsla man , 
utilTties , 
meters , 
trace , 
init ; 



/* entry to init from bootload */ 
entry: istart; 



/* table size specifications */ 

module: hsla__man; 

type: hsla; 

size: 97; 

module: trace; 

type: trace; 

mask: 310000; /* trace enable mask */ 

s i ze : 512; 

end; 
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SECTION 7 



COMMANDS 



This section cbhtairis descriptiohs of commands useful for "channel 
management and site communications administration. 



The conventions shown in the usage lines of these commands are the same as 

those used throughout the set of Multics manuals; briefly, arguments enclosed in 

braces ({}) are optional, and all others are required (unless otherwise noted). 

For a complete description of all the usage line conventions, refer to Section 1 
of the Commands manual. 
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Name : bind_fnp 



The bind_fnp command produces a core image segment that can be loaded into 
the FNP. It uses two control segments: a bindfile, which specifies the configuration 
that the FNP will support, the names and ordering of the object segments included 
in the core image, and the size of certain software tables; and an optional 
search rules segment, which specifies which directories are searched to find the 
object segments. 



Usage 



bind_fnp pathname {-control_args)- 



where: 

1 . pathname 

specifies the pathname of the bindfile. If pathname does not have a 
suffix of bind_fnp, one is assumed. 

2. control_args 

may be chosen from the following: 

-cross_ref, -cref 

adds a symbol cross reference to the listing segment. If -cross_ref 
is specified, the listing is generated regardless of whether -list 
is also specified. 

-list, -Is 

produces a listing segment whose name is derived from the name of 
the bindfile, with the suffix changed to list. The listing segment 
is a record of the binding. It contains a copy of the bindfile, a 
load map, and any error messages generated during binding. 

-search, -se 

indicates that the user wishes to specify the rules used to search 
for Multics Communications System object segments being bound into 
the core image. If given, there must be a segment in the working 
directory containing an ASCII list of relative pathnames of directories 

I to be searched in the order in which the search is desired. By 
default, the working directory is searched. This segment must have 
the same entryname as the bindfile, but with the suffix changed to 
♦* search. 

-version STR 

assigns a version of STR to the core image. The maximum length of 
STR is four characters. If this control argument is given, it overrides 
the version keyword specified in the bindfile. 
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Notes 



A default bindfile is supplied with the system. In general, the only fields 
that a site administrator would" change are: hsTa, Isla, version, order, and the 
size keyword for the trace module. 



When creating a new FNP core image, object segments that are unchanged must 
be extracted from the object archive (see the MPM Commands) into a directory in 
the search list before executing the bind fnp command. 



The syntax of the bindfile is described in Section 6. 
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Name: j^annel comm meters 



The channel_comm_meters command prints out metering information for a 
specified communications channel or channels. 



Usage 



channel comm meters channel name {-control args} 



where : 

1 . channel name 

Ts the name of the channel for which information is to be printed. 
If it is the name of an FNP, totals for that FNP are reported. If 
channel_name is a starname, information for every channel matching 
the starname is printed. 

2. control_args 

can be chosen from the following: 

-brief, -bf 

causes a reduced amount of information to be printed for each specified 
channel . 

-error 

causes only those meters to be printed that reflect error conditions. 

-since bootload, -boot 

pFints the meters accumulated since each channel's parent multiplexer 
(or, in the case of an FNP, the system) was last loaded. This 
control argument is incompatible with -since_dialup (below) . 

-since dialup, -dial 

prints the meters accumulated since the channel last dialed up. This 
is the default. This control argument is incompatible with 
-since bootload (above). 

-summary, -sum 

causes a one-line summary to be printed for each specified channel. 
This control argument may not be specified if either -brief or -error 
is specified. 



Notes 



If a single channel is specified, the caller must either be the current 
user of the specified channel or have access to either the metering_gate gate 
or the phcs gate. If a starname is specified, the user must have access to one 
of the above-named gates. 



If -brief and -error are both specified, then only those error indications 
that would be printed with -brief are printed. See the example below. 
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Examples 



In the example below, code characters appear at the Ireginning of some lines; 
ttiese" "c"h"a'r~ac ter s do "not appear " in t"he actual dutput" of the command . The 
interpretation of the characters is as follows: 

A — this line appears for asynchronous channels only 

S — this line appears for synchronous channels only 

B — this line is among those printed if -brief is specified 

E — this line is araong those printed if -error is specified 

Only lines raarked with both B and E are printed if -brief and -error are both 
specified . 



channel coram_meters a.hOOO 
Total metering time 01:^5:13 



a .hOOO 



[The following meters are printed for all nonmul tiplexed channels:] 



before conversion after conversion ratio 

B Total characters input 984 935 0.95 

B Total characters output 10,540 11,400 1.09 

B Average length of input 8.7 8.3 

B Average length of output 63.1 69.4 

read write control total 

Number of calls 175 194 53 422 

Average time per call (msec.) 2.3 5.8 1.7 4.1 

Average chars, processed per call 5.6 56,1 



Number of software interrupts 113 
Average time per interrupt (msec.) 1.6 



B Effective speed (bps) 1.6 17.5 

[The following meters are printed for physical FNP channels only] 

input output 

SB Messages transmitted 240 224 

SB Minimum message length 5 12 

SB Maximum message length 143 508 

SB Average message length 10.3 57.6 



SBE Invalid input messages 6 (2.5% of total) 

SBE Output messages retransmitted 8 (1.6% of total) 

SBE Timeout waiting for acknowledge 2 (0.4^f of output messages) 

Output overlaps in FNP 127 
Average length of DIA request queue 1.7 entries 



A 




Pre-exhaust status 


12 


A 


E 


Exhaust status 


7 


A 


E 


Software transfer timing errors 


0 


A 


E 


Bell/quits 


8 


A 


E 


Echo buffer overflows 


2 




E 


Parity errors 


0 
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Avg. number of pending status events 1.9 

E Software status queue overflows 1 

E Hardware status queue overflows 0 

E Input buffer allocation failures 1 

[The following meters are printed for an entire FNP] 

FNP has been up for 01:15:12 

B Number of channels configured 88 

B Average number dialed up ^3»7 
B FNP idle 

B Idle at peak load 8.0?; 

input output 

B Characters transmitted 71,966,100 91,931,100 

B Characters per second 1,700 6,200 

E Abnormal DIA status events 3 

E Memory EDAC errors 0 

B Memory size 61K 
B Total available buffer pool 6,360 words 
B Avg. amount of free space 21,876 words 

B Average % of buffer pool available 31.7 

BE Buffer allocation failures 12 

E Output restricted by space 21 

Number of interrupts from this FNP 1,961,208 

Avg. time/interrupt (ms) 3.1 

% of total CPU time 1. 1 

Mailbox transactions: 

Input data 220,319 

Output data 513,210 

Input control 11, 111 

Output control 23,156 



Total 801,126 

Average inbound mailboxes in use 1.1 
Average outbound mailboxes in use 3. 1 

Maximum outbound mailboxes in use 16 

E No outbound mailbox available 37 

E Input rejects 22 
E % of input transactions rejected 0.01 



The following example shows the format of the output of the command when 
the -summary control argument is specified. 

channel comm meters a.hOO* -summary 



cps 


cpsi 


cpso 


iotxXsbepQqa 


err 


ABE 


name 


user 


120 


0.2 


5.1 


xX b Q 


12 


aB 


a .hOOO 


Cor en 


600 


2. 1 


102. 1 


t X a 


73 


s 


a.h005 


ABClone 


30 


0.5 


2.6 


e 


2 


a E 


a.h009 


Parrish 
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The column headings are interpreted as follows: 
cps 

the nominal speed of the channel, in characters per second. 

cpsi 

the effective speed of input over the channel, in characters per second. 

cpso 

the effective speed of output over the channel, in characters per 
second . 

The following flags are printed if the corresponding condition has occurred 
at least once on the channel. 

i — invalid input message 

o — output message retransmitted 

t — timeout waiting for acknowledge 

X — pre-exhaust status 

X — exhaust status 

s — software transfer timing error 

b — bell/quit 

e — echo buffer overflow 

Q — software status queue overflow 
q — hardware status queue overflow 
a — input buffer allocation failure 
err 

the total number of errors of all kinds that have occurred on the 
channel . 

A 

"a" for an asynchronous channel or "s" for a synchronous channel. 

B 

the channel is in breakall mode. 

E 

the channel is in echoplex mode. 

name 

the name of the channel, 

user 

the Personid of the current user of the channel. If the channel is 
not in use, or the user's name is not available, this field is left 
blank . 
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Name : console report 



The console_report command creates and displays metering of terminal usage 
on the system based on the information obtained form the answering service logs. 



Usage 



console report {as log paths} {-control args} 



where : 

1. as_log_paths 

are pathnames of answering service logs. The pathnames can be absolute 
or relative. 

2. control_args 

can be chosen from the following: 

-print 

causes a display of the metering on user_output. 

-report_reset , -rr 

causes a display of the metering on user_output and resets the metering 
in the data base. 

-reset, -rs 

resets the metering in the data base. 

-sort 

sorts the data base alphanumerically by terminal answerback identifiers. 



Notes 



Control arguments and pathnames can appear anywhere in the command line. 
They are processed from left to right, one at a time. 



The header in the display produced when the -print and -report reset control 
arguments are used is obtained from the system titles. This header may be too 
wide for the user's terminal and the user may wish to use the file output command. 



The command creates and stores data into two segments, termseg and termuseg , 
in the current working directory when pathnames of answering-service logs are 
specified. These segments are the data bases that the command expects to find 
in the current working directory when any of the control arguments are used. 
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Example 



Kultics terminal usage 



Period from 


08/26/80 


1407.9 to 


09/25/80 


1600. 2 






Type 


Count 


Logins 


Nologins 


CPU 


Connect 




2741 


247 


28 


17 


0: 05 


25.22 




TN30O 


395 


632 


48 


18: 47 


604: 18 




Daemon 


101 


873 


4 


38: 08 


4456: 06 




ASCII 


1077 


9563 


1423 


531 : 45 


7954: 30 




TELNET 


13 


0 


324 


0: 00 


0: 00 




LA36 


93 


60 


1 1 


0: 34 


15: 40 




VT100 


41 


419 


45 


6: 10 


367: 53 




LA120 


5 


1 12 


q 


2: 24 


89:51 


ID 


Type 


Location 


Logins 


Nologins 


CPU 


Connect 




User 












002 


ASCII 




1 


3 


0:04 


3:03 




Derek 


.Multics 


1 




0: 04 


3:03 


004 


ASCII 




2 


4 


0: CI 


1: 16 




Aulin 


.Mul tics 


2 




0:01 


1:16 


405 


LA 120 




73 


26 


0:46 


75:54 




MKane 


. Network 


38 




0:31 


53:07 




Ma r c u 


s . Network 


8 






6; 09 




In ad a 


. Network 


11 




0:07 


5:53 




SBWeber . Network 


9 




0:05 


6:37 




Ducot 


.FlexMan 


5 




0:01 


3:43 




Yip . Network 






0:01 


0:02 




Feinstein .Network 1 




0:01 


0:27 


40> 


ASCII 






0 


0:01 


0:26 




Stanzel . ARCS 






0:01 


0:03 




AWhite.ARCS 






0:01 


0:24 


40> 


VT100 






0 


0:01 


0:38 




HSPP- 


BASIC. Student 1 




0:01 


0: 16 




Soley 


.ARCS 






0:01 


0:23 



1. 

2. 
3. 



etc . 

where : 
Type 

Count 

Logins 



is the terminal type. 



is the number of different terminals of that type 



are the number of completed logins. 
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4. Nologins 

the number of logins attempted and not completed. 

5. CPU 

is the amount of CPU time used. 

6. Connect 

is the amount of time actually logged in. 



8. Type User 

the terminal type and ID is shown on a heading, followed by a line 
for each user of the terminal giving usage statistics. 

9. Location 

is not used. 



7. 



ID 



is an identification number assigned to a specific terminal. 
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Name: cv cmf 



The cv cmf command converts an ASCII channel master file (CMF) into a binary 
channel definition table (CDT). The binary table can be installed using the 
install command. 



Usage 



cv_cmf cmf_path {-control_args} 
where: 

1 . cmf_path 

is the pathname of the channel master file. If path does not have a 
suffix of cmf, one is assumed. However, the suffix cmf must be the 
last component of the name of the source segment. 

2. control_args 

may be one of the following: 

-brief, -bf 

uses short form of error messages. 

-long, -Ig 

uses long form of error messages. 

-severity N, ~sv N 

causes error messages whose severity is less than N (where N is 0, 
1, 2, 3, or 4) not to be written to the user output switch. If this 
control argument is not specified, a severity level of 0 is assumed 
(i.e., all error messages are written to the user output switch). 



Notes 



If no control arguments are given, each error message is printed in long 
form the first time it occurs and in short form thereafter. 



The converted channel master file is given a name corresponding to the 
entryname of the source segment, with the cmf suffix replaced by cdt. It is 
placed in the working directory. 
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Notes on Severity Values 



The cv_cmf command associates the following severity values to be used by 
the severity active function: 

Value Meaning 

0 No compilation yet or no error. 

1 Warning. 

2 Correctable error. 

3 Fatal error. 

4 Unrecoverable error. 

5 Could not find source. 
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Name: display cdt 



The display cdt command enables a qualified user to display the contents of 
a channel definition table (CDT). 



Usage 



display_cdt {channel} { -control_args} 
where : 

1. channel 

is the name of the communications channel for which the CDT entry is 
to be displayed. The star convention is allowed. 

2. control args 

may be chosen from the following: 

-all, -a 

displays names and CDT indices for all channels in the CDT. 
-brief, -bf 

displays only channel names and CDT indices (without channel or FNP 
details). This is the default for the -all and -subtree control 
arguments . 

-cmf path 

creates a CMF in the segment named path in a form suitable to cv cmf, 
based on the contents of the CDT. ~ 

-header, -he 

displays the CDT header variables in addition to other requested 
information . 

-long, -Ig 

displays detailed information for the specified channel or FNP. This 
is the default unless -all or -subtree is specified, in which case 
-brief is the default. 

-no header, -nhe 

~ suppresses display of the CDT header variables. This is the default. 

-pathname path, -pn path 

displays the CDT whose pathname is path. By default, the CDT in the 
segment >scl>cdt is displayed. 

-subtree 

displays the names and CDT indices for all subchannels (if any) of 
the specified channel. 
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displ ay_cdt 



Notes 

If display_cdt is specified with no channel name and no control arguments, 
a usage error notification is returned. Specifying channel name only, with no 
control arguments, results in a -long display. 



The display cdt command enables the user to check for inconsistencies in a 
CDT before unnecessarily undertaking corrective action. 

The user must have r access to the CDT to invoke the display cdt command. 
Example 

To display the entire system CDT, specify: 

displ ay_cdt -all -header 
To display the system CDT entry for channel a. 1000 only, specify: 

display_cdt a. 1000 
To display all the subchannels of multiplexer a.h026.1, specify: 

display cdt a.h026.1 -subtree -long 
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Name : di5play_fnp_idle 



The display fnp_idle command is used to display information on FNP idle 
time stored by tPTe meter fnp idle command. The display can be in the form of a 
summary or a line graph fTiisfbgram) . 



Usage 



display_fnp idle {fnp_names} { -control-args} 
where : 

1 . fnp_names 

are the names of the FNPs for which idle time information is to be 
displayed. If fnp_names is not specified, the display covers all 
FNPs for which information has been stored. 

2. control-args 

may be chosen from the following: 

-directory path, -dr path 

specifies that information is to be taken from segments in the directory 
with pathname path (see the meter fnp_idle command description for 
idle time segment specifications'! . "The default is to display 
information from idle time segments in the working directory. 

-from DT, -fm DT 

specifies that the display is to cover a period beginning no earlier 
than the date/time DT, which must be in a form suitable for input to 
the convert date to binary subroutine. The default is to start the 
display from the~mo¥t recent idle time segment. 

-histogram, -hist 

causes output in the form of a histogram, where a line shows the 
busy percentage for each FNP at a given time interval. The -histogram 
and -summary control arguments are mutually exclusive, but one or 
the other must be specified. 

-interval N 

specifies that each line in the histogram represents an N minute 
interval. This control argument is ignored if -summary is specified. 
The default is 15 minute intervals. 

-line_length N, -11 N 

specifies the line length of the histogram as N columns (N cannot be 
less than 38) . This control argument is ignored if -summary is 
specified. The default is the user's terminal line length (or 80 if 
output is directed to a file) . 
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-summary, -sum 

requests a summary display of FNP idle information for the specified 
time period. The -summary and -histogram control arguments are mutually 
exclusive, but one or the other must be specified. 

-to DT 

specifies that the display is to cover a period ending no later than 
the date/time DT, which must be in a form suitable for input to the 
convert_date_to_binary subroutine. The default is to end the display 
with the latest available information. 



Examples 



The following command and resultant display represent a sample display_fnp idle 
summary request in which FNP "a" was found to be 90. 3^? idle for the specTfied 
period (i.e., starting from the beginning of the most recent idle time segment 
and including the latest available information). Note that the busiest interval 
within the period is identified. 

display fnp_idle a -summary 

FNP A idle from 01/04/82 0600. to 01/06/82 1436.: 90.3? 

Busiest sample interval: 

01/05/82 1423. to 1424.: 43.7?- idle 



The following command and resultant displ ay represent a sample display_fnp_idle 
histogram request for all FNPs for which idle time has been recorded. The time 
period starts no earlier than noon on 01/06/82 and includes the latest available 
information. The busy percentage for each FNP is given at 10-minute intervals. 



display_fnp_idle -from "01/06/82 1200." -hist -interval 10 

%busy 0 10 20 30 40 50 60 

!!!!!!! 
01/06/82 1330. A EC 

1340. A C B 

1350. A CB 
1400. A B 
1410. A C 

1420. A B C 

1430. A B C 
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Name ; fnp_throughput 

The fnp throughput command reports character throughput for an FNP or all 
FNPs and optTonally allows the resetting of the metering interval. 



Usage 



fnp_throughput {fnp_id} {-control arg} 
where : 

1. fnp_id 

is the name of an FNP or "»", which means all currently running 
FNPs. This argument must be specified unless the -reset control 
argument is specified, in which case fnp id must not be specified. 

2. control_arg 

maybe either, but not both, of the following. If neither is specified, 
information is printed and the metering interval is not reset. 

-report reset, rr 

causes statistics to be printed and the metering interval to be 
reset. If this control argument is specified, fnp_id must be specified. 

-reset, -rs 

causes the metering interval to be reset without printing any statistics. 
If this control argument is specified, fnp id must be omitted. 



Notes 



The start of the metering interval in effect is measured from the time the 
FNP was last booted, or from the time the interval was last reset, whichever was 
the most recent event. 



The reset action of the -report reset control argument applies to the metering 
interval for all FNPs, even thougH the command invocation is specific to the 
statistics for a particular FNP, 
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Example 



To report on throughput statistics for FNP "a" , while resetting the metering 
interval, specify: 

fnp_throughput a -report_reset 

The output would appear as follows: 

input output 
Characters transmitted 71 ,966,^100 94,93^,^00 
Characters per second ii,700 6,200 
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Name ; inap355 



The map355 command is used to assemble a program written in the FNP assembler 
language, map355. The command does not assemble the program directly. Instead, 
it prepares a GCOS job deck to perform the assembly and calls the GCOS Environment 
Simulator to do the work. 



Usage 



map355 pathname {-control args] 



where : 

1. pathname 

is the pathname of the source program to be assembled. The suffix 
of map355 need not be given by the user; it is assumed. 

2. control args 

may be chosen from the following: 

-list, -Is 

creates a listing segment that documents the compilation. The listing 
is created in the working directory, and has a suffix of list. 

-macro file path 

specifies the pathname of the macro file to be used for the assembly. 
If omitted, >ldd>comm>fnp>info>355_macros is used. 

-check 

specifies that the compiler only perform a syntax check of the source. 
No object segment is created. 

-comdk 

creates a GCOS comdk segment. This segment contains a BCD version 
of the source program. It is created in the working directory with 
a suffix of comdk. 

-gcos_list, -gels 

creates a GCOS listing segment in the working directory. This is a 
BCD version of the listing segment. It has a suffix of glist. 

-noconvert 

specifies that the input segment is a GCOS comdk, rather than an 
ASCII segment. If this control argument is used, the source segment 
must have a suffix of comdk. 

-argument list, -ag list 

specifies a list of arguments to be passed to the GCOS Environment 
Simulator . 
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Notes 



This command creates a series of segments for use by the GCOS simulator. 
Some are created in the working directbry, some are created in the process 
directory, and some through links in the working directory to the process directory. 
These segments and links are normally deleted when the command terminates, leaving 
just the object segment, which has a suffix of objdk. 



Refer to the GCOS Environment Simul ator manual, Order No. AN05, for more 
information on the use of th¥" GC(JS~ ErTvironfnent Simulator. 



The map355 command creates links in the working directory to segments to be 
placed in the process directory. If the process terminates in the middle of a 
compilation (new proc or a crash), these links will remain. This means that the 
next time the command is invoked, it will fail because the links point to a 
nonexistent directory. Even though the command fails, the bad links will be 
unlinked and subsequent invocations will work correctly. 



The map?55 command sets the following severity values to be returned by the 
severity active function when the "map355" keyword is used: 



Warning 



Severity 



Value 



Meaning 



0 
1 
2 



No error (or command not yet used) 
The assembly produced warning flags 
The objdk segment could not be created 
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mcs version 



Name ; mcs_version 

The mcs_version command prints the version of the core image most recently 
loaded into the specified FNP. 

Usage 

mcs_version {fnp_tag} 

Syntax as an Active Function 

[mcs_version {fnp_tag}] 

where fnp_tag is the identifier of the FNP whose version is to be printed. It 
can be a,"~b, c, d, e, f, g, or h. If it is omitted, a is assumed. 
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Name: meter fnp idle 



The ineter_fnp_idle command reads FNP idle metering information at specified 
intervals and stores the information in a segment for later viewing through the 
display fnp idle command. 



Usage 



meter fnp idle fnp_name f-control-args} 
where : 

1. fnp_name 

identifies the FNP for which idle time is to be recorded. 

2- control-args may be chosen from the following: 

-directory path, -dr path 

specifies that the segments in which idle time information is to be 
stored are to be created in the directory with pathname path. The 
default is the user's working directory. Segment names are of the 
form fnp_idle data .F .MMDDYY. HHMKSS. I where F is fnp_name, MMDDYY. HHMMSS 
is the startTng date and time of recording, and I is the specified 
interval in minutes. 

-interval N 

specifies that metering information is to be sampled every N minutes. 
The default is 1. 

-stop, -sp 

terminates meter reading on this FNP. No other control argument may 
be specified with -stop. 



Notes 



Information is appended to the idle time segment until the -stop control 
argument is encountered or the process terminates = Maximum length of an idle 
time segment is 6MK (to avoid exhausting a 256K ASTE) . If a segment becomes 
full, a new one is created. On average, taking readings at one-minute intervals 
would fill a S^K. segment in a little over three weeks (if a single process in 
v;hich the command was invoked were to run that long) . 



Each invocation cf the command creates a new segment. 



Use of this command requires access either to the metering gate gate or the 
phcs gate. ~ 
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Example 

The command 

meter_fnp_idle a -interval 5 

creates a segment in the working directory into which will be stored idle time 
meter readings taken on FNP "a" at five-minute intervals. 
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Name : set x25 packet threshold 



The set_x25_paGket_threshold command sets the minimum size of X.25 "long" 
packets. Packets of this size or larger are given lower priority than short 
packets. 



Usage 

set__x25__packet_threshold channel_name packet_size 



where: 

1 , channel__name 

is the name of an X.25 multiplexer channel. 

2. packet__size 

is the minimum length of a long packet, in characters. 



Notes 



If packet_size is set larger than the maximum packet size in use by the 
multiplexer, no packets are given preferential treatment on the basis of size. 

The initial value of the minimum long packet size is determined by the 

"packet_threshold" parameter in the terminal type definition for the 

multiplexer. The present value of the parameter, and the maximum size for all 
packets, is included in the output from the tty_dump cc«nmand. 

Use of this command requires access to the hphcs gate. 
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Name ; system comm_meters 



The system__comm_meters command prints out metering information for ring 
zero Multics Communications Management. 



Usage 



system__comm__meter s { -control__arg s} 



where : 

1, control__args 

can be chosen from the following: 

-reset, -rs 

resets the metering interval for the invoking process so that the 
interval begins at the last call with -reset specified. The 
metering information is not printed. If -reset has never been given 
in a process the interval begins at system initialization time. 

-report_reset , -rr 

prints metering information and then resets the metering interval. 



Notes 



I Use of the system__comm_meters command requires access to the meter ing_gate_ 
and phcs_ gates. 



Example 



The following is a sample of the output of the system comm meters command. 



Total metering time 05:^3:27 



THROUGHPUT 

Total characters input 
Total characters output 
Average length of input 
Average length of output 
Input characters preconverted 



before conversion after conversion 
17,234,567 15,543,210 
168,012,345 185,876,543 
12.3 characters 
59.7 characters 
20,435 (1 ,2% of total) 



ratio 
0.90 
1.14 



Number of calls 
Average time per call 
Average chars, processed 
Average chars, per msec. 



read 

1,456,789 
6.37 msec 

13.5 
2.1 



write 

26,357,924 
9.63 msec 

57.8 
5.8 
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CHANNEL INTERRUPTS 

software "interrupts" 
average time (msec.) 



input 
678, 90.1 
1.3^ 



output 
0.56 



other 
110,011 
0.23 



total 
1,212,352 
1.01 



TTY_BUF SPACE MANAGEMENT 

Total size of buffer pool 
Number of channels configured 
Number of multiplexed channels 

% of buffer pool in use 
input 
output 

control structures 



11,480 words 
1^13 



current 
6.9 
13.4 
15.8 



average 
6.5 
15.6 
15.3 



total 

Smallest amount of free space ever 



36.1 37.4 

4,358 words (38? of buffer pool) 



allocate 

Number of calls 24,657,988 
Average time per call (msec.) 0.23 
% of total CPU 0. 14 

Calls requiring loop on tty_buf lock 
Average time spent looping on lock 
Number of allocation failures 



free total 
20,665,443 45,323,431 
0.?7 0.29 
0.17 0.31 
1,249,340 (2.83? of total) 
0.14 msec. (0.01?, of total CPU) 
0 (0.00% of attempts) 



CHANNEL LOCK CONTENTION 



Times channel lock found locked 
Average time spent waiting for lock 
Maximum time spent waiting for lock 
Number of interrupts queued because 
channel locked 



2,364,758 (5^ of attempts) 
1 . 8 msec . 
3.7 msec. 

25,437 (2.2% of interrupts) 



ECHO NEGOTIATION 

Average time of transaction 
Number of characters echoed 
Number of characters echoed 



3.2 1 

by supervisor 21,576 
by FNPs 335,466 



(0.137- of input chars) 
( 1 . 875^ of input chars) 



ABNORMAL EVENTS 



Input restarts 
Output restarts 
Output space overflows 
"needs space" calls 



12,576 (0.8^ of read calls) 

304,289 (1.2% of write calls) 

16,384 (0.1% of write calls) 
0 
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tty dump 



Name : tty_dump 

The tty_dump command displays on the user's terminal the contents of the 
ring zero data bases describing either the current state of selected communications 
channels managed by the Multics Communication System or the state of such channels 
at the time of a system crash. See the Multics Communication System manual, 
Order No. AN85, for more detailed information. 



Usage 



tty_dump channel_name {-control_args} 



where : 

1. channel name 

specifies the communications channels for which the state is to be 
displayed. The star convention is allowed (e.g., b.h202.**). This 
argument is incompatible with the -user control argument. 

2. -control args 

can be any of the following: 

-user STR 

specifies that the state of all communications channels attached by 
the specified user(s) is to be displayed. STR is a starname used to 
identify the users and is matched against the Person id. Project id 
of each logged in user. For example, "*Smith.M*" would match "any 
user whose Person id ends with "Smith" that is logged in on a project 
that starts with~"M". This control argument is incompatible with 
the channel name argument and the -erf control argument. 

-erf N 

specifies that information about the channels is to be taken from 
the system dump associated with error report form (ERF) N located in 
>dumps. If this control argument is omitted, information about the 
currently running system is displayed. This control argument is 
incompatible with the -user control argument. 

-all, -a 

specifies that, for each channel selected by the above arguments, 
information is to be displayed from the data bases of the channel, 
its parent multiplexer, its grandparent multiplexer, etc., up to the 
top level multiplexer channel. For example, for b.h202.prt1, all 
information from the data bases of b.h202.prt1, b.h202, and b that 
is related to b.h202.prt1 would be displayed. 

-Icte 

specifies that the logical channel table entries (LTE) for the selected 
channels are to be displayed in addition to the other information 
normally displayed. If -all is specified, the LCTEs of all parent 
multiplexers are also displayed. 

-subchan , -sbc 

specifies that information from the data base of the parent multiplexer 
related only to the selected channels is to be displayed. 
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-long, -Ig 

specifies that the contents of any input and output buffers for the 
channels are to be displayed. This is the default. 

-brief, bf 

suppresses display of the buffer contents. Only the addresses, size, 
and flags for each buffer are displayed. 

-ascii 

specifies that the contents of buffers are to be interpreted as 
ASCII characters in addition to being displayed as octal or hexadecimal 
values . 

-ebcdicS 

specifies that the contents of buffers are to be interpreted as 
EBCDIC (8-bit byte) characters in addition to being displayed as 
octal or hexadecimal values. 

-ebcdic9 

specifies that the contents of buffers are to be interpreted as 
EBCDIC (9-bit byte) characters, in addition to being displayed as 
octal or hexadecimal values. 

-octal 

specifies that the contents of buffers are to be displayed as octal 
values in addition to any character interpretation. Octal is the 
default numeric mode for buffer contents display. 

-hex 8 

specifies that the contents of buffers are to be displayed as hexadecimal 
values, in addition to any character interpretation. Each 8-bit 
byte in a word is displayed (nine hexadecimal digits). 

-hex9 

specifies that the contents of buffers are to be displayed as hexadecimal 
values, in addition to any character interpretation. The low order 
8 bits of each 9-bit byte in a word is displayed as two hexadecimal 
digits . 



Notes 



Use of the tty_dump command without the -erf control argument requires 
access to the gate phcs . 



detailed information on the various buffer display formats. 



The default mode for buffer displays is to display their contents as octal 
values without any character interpretation. 



There are two sets of conflicting control arguments in tty_dump: three 
with which to specify the base of numeric display (-octal, -hex8, and -hex9), 
and three with which to specify character code interpretation (-ascii, -ebcdic8, 
and -ebcdic9). If conflicting control arguments are given on the command line, 
the last one specified will be used. 
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tty_dump 



Examples 

The command line: 

tty_dump b.h202.»* -all 

displays the state of mul tiplexer b .h202 and its subchannels . Displayed information 
includes the WTCBs/TCBs of the subchannels, multiplexer-specific data for the 
subchannels, global data for the multiplexer, and the PCB of the multiplexer's 
physical FNP channel. 

By comparison, the command line: 

tty_dump b.h202 -all 
displays only global multiplexer data and the PCB. 
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Name : tty_lines 



The tty_lines command prints information about communications channels defined 
in the channel definition table (CDT). An optional argument can be used to 
print information about a subset of channels. 



Usage 



tty_lines {arg} 



where arg is either a channel name, in which case information about the specified 
channel is printed, or one of the following: 

id STR 

prints information about channels on which the terminal most recently 
dialed up has an identification code specified by STR. The string 
STR is four characters long. 

dlN 

prints information about each channel that has been dialed up N 
times or more. 

d=N 

prints information about each channel that has been dialed up exactly 
N times. 

S*- M 

prints information about each channel whose current state code is N 
(see item 4 in "Notes" below). 

acN 

prints information about each channel whose activity code is N (see 
item 6 in "Notes" below) . 

slN 

prints information about the Nth entry in the CDT. 
-type STR 

prints information about each channel on which the most recently 
dialed terminal was of the terminal type specified by STR. 



Notes 



If the tty lines command is given with no argument, it prints information 
about all channels in the CDT. 



7-27 



CC75-01 



tty lines tty lines 



For each channel, a line is printed in the following format: 
NAME TYPE D S W A BAUD PersDn_id Project_id (ID) C 
where : 



1 . NAME 

2. TYPE 

3. D 

4. S 



5. W 



6. A 



7. BAUD 



is the channel name, e.g., a. 1006. 



is the terminal type that has most recently dialed the channel, or 
NU if the channel has not been used. 



is the number of times the channel has been dialed up. 



is the current state of the channel. It may have one of the following 
values : 

1 hung up 

2 listening (ready for dialup) 
5 dialed 

is an internal variable indicating what the answering service expects 
to happen next to the channel. 

is the activity code for the channel. It may have one of the following 
values : 

1 hung up 

2 listening (ready for dialup) 

3 dialed up but not logged in 

4 user is logged in but process not yet created 

5 user process has channel 

6 auto call line is in process of dialing out 

7 auto~call line is in use (dial complete) 



is the baud rate of the channel 



8. Person_id 

is the Person id of the current user of the channel. If A is not H 
or 5, this field is omitted. 

9. Project id 

Ts the Project id of the current user of the channel. If A is not 4 
or 5, this fieTd is omitted. 



10. ID 



11. C 



is the identification of the terminal currently using the channel. 
If S is not 5, this field is omitted. 



is the comment field from the CDT entry. 
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SUBROUTINES 



This section contains descriptions of subroutines useful for channel management 
and site communications administration. 



The conventions shown in the usage lines of these subroutines are the same 
as those used throughout the set of Multics manuals. 
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Name: comra meters 



The comm meters subroutine, given a list of communications channel names, 
returns metering infoTmation for all the specified channels. The exact information 
returned for each channel varies depending on the line type and multiplexer type 
of the channel. Callers of comm meters should later call the comm meters $free 
entry point to release the space~allocated for the returned meter ing~in formation . 



Usage 



del comm_meters entry ((*) char (32), fixed bin, pointer, fixed bin, 
pointer, fixed bin (35)); 

call comm meters (chan names, version, area ptr, n channels, 
chan~meter s~ptr , code); 



where : 

1. chan_names (Input) 

is an array of channel names, any of which may be starnames. 

2. version (Input) 

is the version number of the channel meters structure to be returned. 
It must be 1. ~ 

3. area_ptr (Input) 

is a pointer to an area in which the returned metering information 
is to be allocated. It must be a nonnull pointer. 

4. n_channels (Output) 

is the number of channels for which metering information is returned. 

5. chan_meters ptr (Output) 

is a pointer to a linked list of structures containing the returned 
metering information. 

6. code (Output) 

is a standard system status code. 



The structure pointed to by chan_irieter s_ptr has the following format, which is 
defined in the include file channel_meter s . incl .pi 1 : 

del 1 channel meters aligned based (chan_meterp) , 
2 version fixed bin, 
2 mul tiplexer_type fixed bin, 
2 parent_type fixed bin, 
2 line_type fixed bin, 
2 flags, 

3 reserved bit (36) unaligned, 
2 padi fixed bin, 
2 channel_name char (32), 
2 mpx specific meterp pointer, 
2 parent meterp pointer, 
2 next cTTannelp pointer, 
2 cumuTative, 

3 unconverted input chars fixed bin (35), 
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3 converted_output_chars fixed bin (35), 
3 read calls fixed bin 
3 write_calls fixed bin, 
3 eontrol_calls fixed bin, 
3 softws'^® i"^^*"'*"P^^ fixed' bin, 
3 read__calT time fixed bin (71), 
3 write_calT time fixed bin (71), 
3 control_caTl_time fixed bin (71), 
3 interrupt time fixed bin (71), 
3 pad (4) fixed bin, 
2 saved like channel meters. cumulative ; 



version 

contains the value of the version argument (above). 
multiplexer_type 

is the multiplexer type of the channel. It may have any of the values 
defined in multiplexer_types.incl.pl1. 

parent type 

i¥ the multiplexer type of the channel's parent multiplexer. If the 
channel is a level-1 multiplexer (i.e., top-level multiplexer), 
parent_type is set to -1. 

line_type 

is the line type of the channel. It may have any of the values defined 
in line_types.incl.pll. 

flags 

are reserved for future use. 

channel name 

is~the name of the channel. 

mpx_specific meterp 

is a pointer to additional meters that vary according to multiplexer 
type. 

parent_meterp 

is a pointer to additional meters maintained on behalf of the channel 
by its parent multiplexer. If the channel is a level-1 multiplexer, 
this pointer is null. 

next channelp 

~is a pointer to the channel meters structure for the next channel in 
the list. If this is the last channel, next_channelp is null. 

cumulative 

contains meters for the channel accumulated since the most recent bootload 
of the system. 

unconverted input_chars 

is the~number of characters input on the channel before conversion at 
the channel's multiplexing level. 

converted output chars 

is tEe number of characters output on the channel after conversion. 
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read calls 

~is the number of calls to channel_manager$read for this channel, 
write calls 

Ts the number of calls to channel_manager$wr ite for this channel. 
control_calls 

is the number of calls to channel manager$control for this channel. 

software interrupts 

is The number of calls to channel_manager$interrupt for this channel. 

read_call time 

is tEe amount of time (in microseconds) spent in read calls. 

write call_time 

Ts the amount of time spent in write calls. 

control call time 

is the amount of time spent in control calls. 

interrupt time 

is tEe amount of time spent processing software interrupts. 

saved 

contains meters saved the last time the channel dialed up. They can 
be used in combination with the cumulative meters above to derive 
statistics for the current dialup session. 



Notes 



If comm meters encounters an error, it calls the sub err_ subroutine, raising 
the sub error condition with the restart flag on. The~struc ture pointed to by 
sub err~info .Fnfo ptr has the following format, which is defined in the include 
file comm meters error info .incl .pll : 



del 1 comm meter s_error_info aligned based (comm_meters_errp) , 
2 versTon fixed bin, 
2 Chan name char (32), 
2 flags, 

3 starname_matched bit (1) unal, 
3 more than one_starname bit (1) unal, 
3 more~than one_match bit (1) unal, 
3 pad ¥it (33) unal; 



version 

is the version number of the structure. It is set to comm_meters_err_v1 . 
chan name 

~ is the name of the channel being processed when the error was encountered. 
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starname matched 

"Ty'b error was encountered while matching a starname 
"1"b a starname provided by the caller was matched 

more_than one starname 

"©"""b tEe caller provided no more than one starname to chan names 
"1"b more than one starname was provided ~ 

more_than one match 

"1'"'b sfarname currently being processed was matched by more than one 
channel name 

Meaningless if starname matched (above) is not "1"b 



Entry : comm_meters_$free 

This entry is called to release space allocated by coram meters to return 
metering information. Any program that calls comra meters sTiould subsequently 
call coram meters $free to release the allocated space. ~ 



Usage 

del comm meters $free entry (pointer, pointer, fixed bin (35)); 
call comm_meters_$free (area_ptr, chan_meter s_ptr , code); 

where : 

1. area_ptr (Input) 

is a pointer to the area in which the space was allocated. 

2. chan_meters_ptr (Input) 

is a pointer to the list of metering structures returned by comm_meters 
(above) . 

3. code (Output) 

is a standard system status code. 



Entry ; meter ing_gate_Sget_comm_meters 

This entry is identical in function to phcs_$get comm meters; it exists for 
the use of callers who lack access to the phcs_ gafe. The arguments are the 
same as for phcs $get comm meters. 
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Name : MPX_meters_ 

This is a generic name for a collection of utility subroutines for managing 
meters specific to various multiplexer types. The string "MPX" in the name 
represents the name of a multiplexer type , as defined in mul tiplexer_types .incl .pi 1 ; 
thus, the actual subroutines have names such as tty_meters_, mcs meters , 
vip7760 meters , etc. 



Entry : MPX_meter s_$allocate_mpx 

The allocate_mpx entry allocates a structure for meters maintained by a 
multiplexer for channels of that multiplexer type; 
vip7760_meters_$allocate_mpx allocates the metering structure for a vip7760 channel 
itself. 



Usage 

declare MPX_meters_$allocate_mpx entry (pointer, pointer, fixed bin (35)); 
call MPX_meters_$aHocate_mpx (area_ptr, meter_ptr, code); 

where : 

1. area ptr (Input) 

~ is a pointer to an area in which the metering structure is to be 
allocated . 

2. meter ptr (Output) 

is a pointer to the allocated metering structure, whose format depends 
on the multiplexer type. If the entry is being called in preparation 
for a call to metering_gate_$get_comm_meter s , the value of this pointer 
should be assigned to get comm_meter s_info .subchan_ptr . 

3. code (Output) 

is a standard system status code. 



Entry : MPX_meters_$allocate_subchan 

This entry allocates a structure for meters maintained by the multiplexer 
for its subchannels; e.g., vip7760 meter s_$allocate_subchan allocates space for 
meters kept by the vip7760 multiplexer modules for subchannels of a vip7760 
channel . 
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Usage 

declare MPX. meters ^allocate suhchan entry ( pointer , .pointer , fix-ed bin 
(35));~ 

call MPX meters !l?allocate_subchan (area_ptr, meter_ptr , code); 

Arguments are the same as for the allocate mpx entry, above. If the entry is 
called in preparation for a call to meter ing~gate_$get_comm_meter s , the value of 
meter ptr should be assigned to get comm meters info. parent ptr. 



Entry : MPX_meter s_$free_ffipx 

This entry is used to free the storage allocated by the MPX meter s_$allocate mpx 
entry, above. 

Usage 

declare MPX_meter s_$free mpx entry (pointer, fixed bin (35)); 
call MPX meter s_$free_mpx (rneter^ptr, code); 

where : 

1. meter_ptr (Input) 

is a pointer to the metering structure to be freed. 

2. code (Output) 

is a standard system status code. 



Entry : MPX meter s_$free_subchan 

This entry is used to free the storage allocated by the 
MPX_meter s_$allocate_subchan entry, above. 

Usage 

declare MPX meter s_$free_subchan entry (pointer, fixed bin (35)); 
call MPX meter s_$free_subchan (meter_ptr, code); 

Arguments are as for the free mpx entry, above. 
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Entry : MPX meter s_$display_mpx 

This entry displays, on a specified I/O switch, the meters associated with 
a multiplexer of the specified type. The format of the statistics displayed 
depends on the type of multiplexer. These entries are called by commands that 
display general communications meters. 



Usage 



del MPX meters $display_mpx entry (char (»), pointer, pointer, bit (36) 
aligned, Tixed bin (35)); 

call MPX meter s_$display_mpx (chan_name, iocb_ptr, meter_ptr, flags, code); 



where : 

1. Chan name (Input) 

is the name of the multiplexer channel for which statistics are to 
be displayed. 

2. iocb ptr (Input) 

is a pointer to the I/O control block for the I/O switch on which 
the meters are to be displayed. If it is null, the user_output 
switch is used. 

3. meter_ptr (Input) 

is a pointer to the structure returned by the comm meters subroutine 
for the channel specified by chan name (above). " 



flags (Input) 

indicates the control arguments specified to the channel comm meters 
command to control the format of the output. The individuaT flags 
are defined as follows: 

bit 1 - "1"b if -brief specified 

bit 2 - "1"b if -error specified 

bit 3 - "1"b if -summary specified 

bit i| - "1"b if -since_bootload specified 

bits 5-36 - reserved 



These values are defined 
comm meters disp flags .incl .pi 1 . 



in 



the 



include 



file 



code (Output) 

is a standard system status code. 
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Entry: MPX meters $display subchan 

This entry displ ays , on a specified I/O switch, meters kept by a multiplexer 
of the specified type on behalf of one of its subchannels. The format of the 
displayed meters depends on the multiplexer type. 



Usage 

del MPX meters $display_subchan entry (char (*), pointer, pointer, bit (36) 
aligned, Tixed bin (35)); 

call MPX_meter s_$display_subchan (chan_name, iocb_ptr , meter_ptr, flags, 
code) ; 

Arguments are the same as for the display mpx entry, above. 



P-9 



CC75-01 



metering gate $comm chan star list 



metering gate $comm chan star list 



Name : metering gate $comm chan star list 



This entry returns a list of communications channel names that match a 
given starname, along with information on each channel's multiplexer type and 
line type. 



declare metering gate_$comm chan_star list entry (char (*), fixed bin, 
pointer, poTnter , fixe^ bin (35)T; 

call metering_gate $comm_chan star_list (starname, version, area_ptr, 
chan_star_lis^_ptr , codeT; 

where : 

1. starname (Input) 



is the starname to be matched. Its length must not be more than 32 
characters. See the description of starnames in the MPM Reference 
Guide for information on the construction of starnames. 



2. version (Input) 

must be 1. 

3. area ptr (Input) 

~ is a pointer to an area in which the channel information is to be 
allocated. It must be a nonnull pointer. 

4. chan star list ptr (Output) 

~ is~a pointer to the structure in which the channel information is 
returned. See "Notes," below, for a description of this structure. 

5. code 

is a standard system status code. It may have one of the following 
values : 



error table_$badstar 

s"tarname is not a valid starname. 

error table $nomatch 

no charTnel names were found that match starname. 

error table $noalloc 

There was insufficient space to allocate the structure for 
the channel information. 

error table_$unimplemented_version 

^e version argument (above) did not contain the current 
version of the information structure. 

0 

no errors. (Output) 



Usage 
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metering_gate_$comm_chan_star_list metering__gate_$comm_chan star list 



Notes 



The structure pointed to by chan_star_list_ptr has the following format 
(described in chan_star_info.incl.pl1): 



del 1 Ghan_star_info based (chan_star_list_ptr ) aligned, 
2 version fixed bin, 
2 n_channels fixed bin, 

2 chan_entry ( chan_star_count refer (chan_star_info.n_channels) ) , 
3 name char (32), 
3 mpx_type fixed bin, 
3 parent_type fixed bin, 
3 line_type fixed bin; 



version 

is the version number of the structure. 
n_channels 

is the number of channels matching the starname. 
chan_entry 

contains information for each channel matching the starname. 

name 

is the name of the channel. 
mpx_type 

is the multiplexer type of the channel. It may have any of the values 
defined in mulitplexer_types . incl .pi 1 . 

is" the multiplexer type of the channel's parent multiplexer. If the 
channel is a level-1 multiplexer, parent_type is -1. 

line_type 

is the line type of the channel if the channel is a physical subchannel 
of an FNP, in which case it may have any of the values defined in 
line_types.incl.pl1 ; otherwise, it is 0. 
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phcs $get comm meters phcs $get coram meters 



Name: phcs $get comm meters 



This entry is used to copy communications metering information for a 
specified channel from ring 0 ,• Logical channel meters for the specified channel 
are returned, as are any multiplexer-specific meters maintained for the channel 
by its own multiplexer module or that of its parent. 



Usage 

del phcs_$get_comm_meters entry (char (*), pointer, fixed bin (35)); 
call phcs_^$get_comm_meters (chan_name, info_ptr, code); 

where : 

1. chan_name (Input) 

is the name of the channel. 

2. info__ptr (Input) 

is a pointer to a structure of the same form as that described for 
the get__meters control order described in the tty_ description in 
the Subroutines manual. 

3. code (Output) 

is a standard system status code. 
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APPENDIX A 



DIRECTIONS FOR SETTING UP SYSTEM-SUPPLIED MULTIPLEXERS 



This appendix describes various aspects of the administration and use of 
the system- supplied multiplexers on Multics: 

» HASP workstations or HASP hosts 

B IBM3270 

B polled VIP 

B software- simulated terminals 

B X.25 network connections 

B foreign system connections through a protocol converter 



ADMINISTRATION AND USE OF HASP WORKSTATIONS AND HOST SYSTEMS 



Multics provides support for the HASP communications protocol. Multics can 
be configured to operate either as the host or as the workstation. As a host, 
Multics communicates with a remote workstation that is usually a remote- 
job-entry (RJE) terminal with an operator's console and one or more card 
readers, line printers, and card punches. As a workstation, Multics simulates 
an RJE terminal and communicates with a remote host system. 



The HASP communications protocol is supported by using the demultiplexing 
features of the Multics Communications System. This mechanism allows each 
device of the remote workstation or each simulated device, when Multics is the 
workstation, to be controlled independently by separate processes. Each device 
must be configured as a slave channel. 



A process using a device channel should attach that channel through either 
the hasp_workstation_ or hasp_host_ I/O module described in the Subroutines 
manual . 



The FNP Core Image 



Support of the HASP communications protocol requires that the proper 
software be loaded into the FNP supporting the terminal or remote system. The 
two modules, bsc_tables and hasp_tables, must be bound into the core image 
before the FNP is loaded. (See Section 6 ("FNP Core Images") and the 
description of the bind fnp command in Section ?.) 
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Definition of HASP Channels 



HASP channels, like all communications channels, are defined in the Channel 
Master File (CMF). An entry must be made in the CMF for the remote workstation 
or host (the multiplexer channel) and for each of the individual devices. A 
sample excerpt from a CMF is shown below. 



name: a.hOl4; 
service: multiplexer; • 
multiplexer_type : hasp; 
line_type: BSC; 
baud: 4800; 

terminal__type : HASP_WORKSTATION ; 

name: a.hOl4.opr; 
service: slave; 
line_type: BSC; 

name: a.hOl4.rdrl-a.h014.rdr3; 
service: slave; 
line_type: BSC; 

name: a.h0l4.prt1-a.h0l4.prt5; 
service: slave; 
line_type: BSC; 

name: a.h0l4.pun1; 
service: slave; 
line type: BSC; 



/* the workstation itself */ 



/* entry for operator's console */ 



/* entry for three card readers */ 



/* entry for five line printers 



/* entry for one card punch */ 



The above configuration defines a remote workstation with an operator's 
console, three card readers, five line printers, and a single card punch. For 
the major channel (a.h014), the line_type, service, and multiplexer type must be 
specified exactly as shown. The terminal type is used to distingulTsn between a 
connection to a remote workstation and one to a host and to specify options 
controlling the connection. (This mechanism is described in detail in "Multiplexer 
Terminal Types," below.) 



The names of the subchannels (a.h014.*) must be created according to the 
following rules: 

• An operator's console must be included in every multiplexer. The console 
is the subchannel whose final component name is "opr." 

• A maximum of eight card readers are permitted. A card reader is a 
subchannel whose final component name is of the form "rdrN", where N 
is a single digit between one and eight. 

• The combined number of line printers and card punches must not exceed 
eight. For example, a multiplexer may have eight line printers and no 
card punches, or three line printers and five card punches; however, a 
multiplexer cannot have five line printers and five card punches. A 
line printer is a subchannel whose final component name is of the form 
"prtN", where N is a single digit between one and eight. A card punch 
is a subchannel whose name final component is of the form "punN", 
where N is also a digit between one and eight. 

NOTE: Due to a restriction in the HASP communications protocol, a 
multiplexer may not contain a line printer and card punch whose device 
addresses total nine. (For example, "prt4" and "pun5" can not be 
configured in the same multiplexer.) 
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Multiplexer Terminal Types 



All terminal types, including multiplexer terminal types, are defined in 
the Terminal Type File (TTF) . The standard Multics TTF does not contain any 
HASP multiplexer terminal types. 



The Multics HASP support must distinguish between communicating with a 
workstation and a host. Additionally, the software must also be aware of certain 
characteristics of the communications channel (e.g. , maximum message block length) . 



The configuration information for a HASP multiplexer channel is supplied by 
using the value of the additional_info keyword of the multiplexer channel's 
terminal type. The additional_info value is formatted as a series of parameter 
assignments, separated by spaces or commas. Each parameter assignment has the 
following form: 

<parameter type>=<parameter value> 



A sample TTF entry for a multiplexer terminal type might appear as follows: 

terminal_type : HASP HOST; 
additional info: 'Typeshost, block size=512, signon mode=no"; 



The complete set of parameters that may be specified is shown below (defaults 
are provided for all omitted parameters) . 

name: type 

values: workstation or host 
default: workstation 

meaning: specifies whether this multiplexer is connected to a remote 
workstation or a remote host. 

name: block_size 

VajLUC^O. •^KJKJ i^lii wugii iKj I f 

default: 400 

meaning: specifies the maximum block size, in characters, used by Multics 
for all messages transmitted on the multiplexer channel. 

name: signon mode 

values: yes or~no 
default: no 

meaning: when connecting to a remote host, specifies that Multics must 
transmit a SIGNON control record to identify Multics to the remote 
host before any data may be transmitted; this parameter is ignored 
when connecting to a workstation. 

name: multileave mode 
values: yes or no 
default: yes 

meaning: specifies that blocks transmitted by Multics may contain records 
from more than one device. This parameter may need to be turned 
off for communications with some workstations. 

name: suspend all mode 
values: yes or no 
default: no 

meaning: specifies that when Multics wishes to temporarily stop input for 
a specific device (flow control), the system will instead request 
that all input be suspended. This parameter may need to be turned 
on for communications with some workstation (e.g., an IBM System/370 
running the HASP workstation simulation option of RSCS under VM/370) . 
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name: rts mode 

values: yes~or no 

default: yes if type is host; no if type is workstation 

meaning: specifies whether Multics will request permission from the remote 
host or workstation before transmitting data on other than the 
operator's console. 

name: connect timeout 

values: 1 throug"h 60 or none 
default: 30 

meaning: when connecting to a remote host, specifies the period (in seconds) 
to attempt the initial connection sequence after the physical 
connection is established; when connecting to a remote workstation, 
specifies the period to wait for the initial connection sequence 
after the physical connection is established. If the string "none" 
is used, the multiplexer will either wait or send the initial 
connection sequence indefinitely as appropriate. 

name: receive_timeout 
values: 1 through 60 
default: 3 

meaning: specifies the period Cin seconds) to wait for a message to be 
received from the remote workstation/host before assuming that 
the last block transmitted by Multics was lost and should be 
retransmitted . 

name: transmit timeout 

values: 1 througTi 60 
default: 2 

meaning: when connecting to a remote host, specifies the period (in seconds) 
for the FNP to wait for a block from Multics to be transmitted 
before automatically acknowledging the last block received from 
the host; this parameter is ignored when connecting to a remote 
workstation . 



name: max naks 

values: 5 tHrough 100 
default: 10 

meaning: specifies the maximum number of consecutive NAKs that may be 
transmitted or received by the FNP on the communications channel 
without an intervening block before aborting the connection, 

name: max device input records 

value: 3 tTTrough "50 
default: 6 

meaning: specifies the maximum number of records that the multiplexer will 
hold as input for a subchannel before requesting the remote system 
or workstation to suspend transmission for that subchannel. For 
optimum operation, this parameter should be given a value that is 
larger than the average number of records in an input block as 
reported by channel comm meters for the multiplexer channel. 



Subchannel Terminal Types 



All data transmitted over a HASP subchannel must be both translated to the 
character set, normally EBCDIC, of the remote host or workstation and formatted 
according to the rigid requirements of the HASP communications protocol. 
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These functions are performed by the hasp_host and hasp_workstation I/O 
modules described in the Subroutines manual. A terminal type may be specified | 
in the attach descriptions of these I/O modules to define the remote host's or 
workstation's character set. See the section "Character Set Specification" in 
the descriptions of these I/O modules for more information. 



Control Orders Used by HASP Subchannels 



The following control orders are recognized for HASP subchannels in 
addition to the control orders defined in the description of the tty_ I/O module 
in the Subroutines manual. These control orders are intended to be used | 
exclusively by the hasp_workstation_ and hasp_host_ I/O modules and should not 
be invoked by user programs. 



In the following descriptions, the "info_ptr" field supplies the 
declaration of the item that must be supplied by the caller to the HASP 
multiplexer software. An indication is also supplied as to whether the caller 
must also supply any information in the field before issuing the control order 
(Input vs. Output). 

name: get_device_type 

function: returns the type of device (operator's console, card reader, line 

printer, or card punch) connected to the subchannel. 
info_ptr: fixed binary (35) (Output) 

notes: the possible values returned by this control order are defined in 

the include file hasp_dev iGe_data_incl .pll . 
return codes: 

0 the device type is supplied in the given field 
error_table_$ undef ined_order_request 

this channel is not part of a HASP multiplexer. 

name: signon_record 
name: no_signon_record 

function: see the section "SIGNON Processing" in the write-up of the 
hasp host I/O module in the Subroutines manual. 



ADMINISTRATION AND USE OF IBM3270 TERMINALS 



Multics provides support for IBM Model 3271 terminal systems as login 
devices. These systems comprise a cluster of keyboard/display stations and 
receive-only printers that can be connected to Multics via a single shared 
communications line. Multics uses the IBM3270 bisync protocol to control these 
dev ices . 



The IBM327O terminal system is supported using the demultiplexing features 
of the Multics Communications System. This allows each device on the controller 
to be controlled independently by separate processes. Each keyboard/display 

station can be ccnfigursd as either 3 login device or 3 slave channel; 
receive-only printers can only be configured as slave channels. 



Note that configuring an IBM3270 channel for use as a multiplexer is 
incompatible with the existing ibm3270_ I/O module, which requires that the 
channel be configured as a slave. A 3270 terminal system can be controlled by a 
single process as a slave device by using ibm3270_, or can be controlled by 
multiple processes as login devices using the IBM3270 demultiplexer. 
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The FNP Core Image 



Support of IBM327O terminals requires that the proper software be loaded 
into the FNP supporting the terminal. The two modules required are bsc_tables 
and ibm3270_tables. Both of these modules must be bound into the core image 
before the FNP is loaded. (See Section 6 ("FNP Core Images") and the description 
of the bind__fnp command in Section 7.) 



Definition of IBM3270 Channels 



IBM3270 channels, like all communications channels, are defined in Channel 
Master File (CMF). An entry must be made in the CMF for the subsystem or 
controller and for each of the subchannels. A sample excerpt from a CMF is 
shown below. 



name: a.h012; /* entry for controller */ 

baud: 9600; 
line_type: BSC; 
service: multiplexer; 
multiplexer_type : ibm3270; 
terminal_type: IBM3271; 

name: a.h012.d00-a.h012.d03; /* entry for U displays */ 
attributes: hardwired, dont_read_answerback; 
line_type: BSC; 
service: login; 
terminal_type: IBM3277_M2; 

name: a.h012.p04; /* entry for 1 receive-only printer */ 
line_type: BSC; 
service: slave; 
terminal type: IBM3284 M2; 



The above configuration defines a system with four keyboard/display stations 
and one printer. For the major channel (a.h012), the line_type, service, and 
multiplexer_type must be specified exactly as shown. The terminal type is used 
to distinguish between various types of 3270 subsystems, and is explained below. 



The names of the subchannels (a.h012.*) must be in a specific format. The 
final component must be exactly three characters. The first character must be 
"p" for printer channels or "d" for keyboard/display stations. The final two 
characters must be two decimal digits that define the device address. The multiplexer 
cannot be configured with a printer and a display that have the same address. 



Multiplexer Terminal Types 



The terminal type for the multiplexer channel specifies options to distinguish 
between various kinds of 3270 systems. The following standard multiplexer terminal 
types are defined in the Terminal Type File (TTF) (additional types may be 
defined by an administrator, as required): 

IBM3271 
IBM3271 ASCII 
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The IBM327I terminal type is for use in configurations using the EBCDIC bisync 
protocol. The IBM327I ASCII type is for use with the ASCII protocol. 



The only portion of the TTF entry for the multiplexer terminal type that is 
used is the "aciditional_info" keyword. The character string is used to specify 
the value of various parameters used to control multiplexer operation. The 
field is formatted as a series of parameter assignments, separated by spaces. 
Each parameter assignment has the following form: 

<parameter type>= <parameter value> 



A sample TTF entry for a multiplexer terminal type might appear as follows: 

terminal_type : IBM3271 ; 
additional info: "controller address=1 quit=pa2"; 



The complete set of parameters that may be specified is shown below (defaults 
are provided for all omitted parameters). 



name: controller_address 
values: 0 through 31 
default: 0 

meaning: specifies the device address of the controller to be used for 
polling. (Multiple controller configurations on a single 
communications channel are not supported.) 



name: quit 

values: pal, pa2, or pa3 

default: pal 

meaning: specifies which function key is to be interpreted as the Multics 
quit function. 

name: formfeed 

values: pal, pa2, pa3, or clear 

default: clear 

meaning: specifies which function key is to be interpreted as restarting 
output on an end-of-page situation. 

name: code 

values: ascii or ebcdic 

default: ebcdic 

meaning: specifies which character code is to be used. 

name: allow raw3270 

values: yes oF no 
default: yes 

meaning: specifies whether users of subchannels of this multiplexer may 
use the special mode "raw3270". This mode is intended for forms 
control and is explained in more detail below. 
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name: allow_copy 
values: yes or no 
default: no 

meaning: specifies whether or not users of raw3270 mode may make use of 
the 3270 copy function. Enabling this function allows a user of 
one subchannel to "copy" the memory of another subchannel. This 
could, in malicious hands, compromise the passwords of users on 
other subchannels. 



name: debug 
values: yes or no 
default: no 

meaning: specifies that the ring-0 portion of the 3270 demultiplexer m.ay 
write certain debugging information on the syserr console. This 
is used only by demultiplexer developers. 



Subchannel Terminal Types 



Terminal types for subchannels are also provided in the standard TTF. The 
following terminal types, which correspond to IBM model numbers, are provided: 

displays: IBM3277 Ml 

IBM3277~M2 

IBM3277~M1 ASCII 

IBM3277~M2~ASCII 
printers: IBM3284 Ml 

IBM328M~M2 



Typing Conventions 



A 3270 subchannel is not considered usable (or dialed) until some input is 
received from it. Therefore, the first step in using a 327O keyboard/display is 
to activate or press any of its input keys (usually "enter", but "clear", or any 
of the "pa" or "pf" keys may be used also). In response to this first input 
(which is discarded) , Multics clears the screen and sends the standard greeting 
message . 



The 3270 demultiplexer uses an unformatted screen in controlling the display. 
It also controls the keyboard unlocking feature and only unlocks the keyboard 
when the process is ready for more input. Unlocking of the keyboard can be 
regarded as a prompting function; the previous input has been acted upon, and 
the process is ready for input again. 



When typing input on a 327O display unit, the following rules must be 

followed: 

1. Always begin typing where the system positions the cursor. 

2. Always leave the cursor after the last character of input. Local 
editing functions of the terminal may be used to edit an input line, 
but the cursor must always be returned to the end of the line of 
input . 

3. Always terminate input with the "enter" key. 

Never attempt to send more than one line of input using the return key 
of the terminal. Single lines of input longer than the line length of 
the terminal may be sent normally by allowing the terminal to wrap at 
the end of the line (except on the last line of the screen). Multiple 
lines are not possible. 
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5. When typing over a password mask (printer_off is not supported), either 
space out over the end of the mask (after the password is typed), or 
use the erase eof function to delete the end of the mask. One of 
these options must be performed before using the "enter" key. Failure 
to do this properly results in part of the password mask being interpreted 
as input. 

6. The terminal's tab key may not be used to enter tabs into the input 
text. The only way to enter a tab is to use the escape sequence (611. 



These typing conventions must be followed exactly. Failure to do so may 
cause input to be ignored, lost, or misinterpreted. 



The formfeed function code (normally pal) as defined In the multiplexer 
terminal type has two uses. First, when output is suspended at the end of the 
screen (EOP on the last line) , the formfeed causes the next page of output to be 
sent. If the terminal is not in an EOP situation, it causes the screen to be 
cleared and new input and output to begin at the top of the screen. 



The 3270 does not implement the full ASCII character set. Therefore, the 
following conventions are used: 

ASCII 3270 

\ (6 (cent sign) 

[ t< 

] )6> 

{ j6( 

} «i) 

~ 6t 

These conventions are the same as used by Multics for IBM27^1 terminals. 



raw3270 Mode 



The 3270 demultiplexer implements a special mode named "raw3270". This 
mode is set and reset like all other tty modes, using the same command and 
subroutine interfaces. This mode is intended for forms programs, and is used to 
make the full set of 3270 features available to tlie user. The mode may be set 
by the user (if allowed by the multiplexer terminal type, see above) at any 
time. It does not go into effect, however, until rawo and rawi modes are also 
set. When raw3270 mode is in effect, the user is expected to format a complete 
3270 bisync message, including the SIX and ETX, but excluding the leading SYN 
and the trailing block check characters. This message, with some minimal checking, 
is sent unchanged to the terminal. The function code (following the STX-ESC) 
may be either write, erase write, or copy (if allowed by the multiplexer terminal 
type). Read buffer, read "modified , and erase all unprotected are not supported. 



When raw3270 mode is in effect, input is not interpreted by the multiplexing 
software (except for messages caused by the TEST REQ key); it is passed to the 
user exactly as received from the terminal. The only change that occurs is to 
combine multiple input messages from the terminal into a single bisync message 
when the terminal has split its input into multiple records because it exceeded 
256 characters. 
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Also, when raw3270 mode is in effect, the hndlquit mode takes on an additional 
meaning. If hndlquit is on, the quit key defined for the multiplexer is processed 
normally; this function key is unavailable for user programs. If the channel is 
in ^handlquit mode, no quit processing takes place and the quit key may be used 
by the application as it sees fit. Note that in ^hndlquit ,raw3270 mode there is 
no way to perform a Multics quit function. 



Special care must be taken by the application program when operating in 
raw3270 mode. Any unexpected output to the terminal (e.g., messages from other 
users, memos, and error messages) will be ill-formatted, may not appear on the 
user terminal, and may have unpredictable side effects. It is important for the 
application program to anticipate all possible error conditions, because the 
default error handler may not return the terminal to a usable state when a 
condition occurs. Thus, in raw3270 mode, when an error occurs, and the user is 
returned to command level, there may be no way for him to enter a command since 
the process is expecting complete bisync messages from the terminal. 



ADMINISTRATION AND USE OF POLLED VIP TERMINALS 



The Multics Communications System provides support for several Honeywell 
VIP terminal subsystems including the VIP7700, VIP7760, and VIP7804. These 
subsystems typically comprise a number of keyboard/display stations and receive-only 
printer stations that can be connected to Multics via a single communications 
line. The Honeywell polled VIP communications protocol supports these terminals. 



The Multics Communication System contains a multiplexing mechanism that 
allows each station of a polled VIP subsystem to be independently controlled. 
Thus, each keyboard/display station can be used as a separate login terminal. 
Similarly, each printer station can be used as a slave device attachable by any 
authorized process, such as an I/O daemon (see Multics Bulk I/O for information 
about I/O daemons) . 



The FNP Core Image 



Support of polled VIP terminals on Multics requires that a particular software 
module, known as polled vip tables, be present in the FNP core image. To accomplish 
this, the bindfile mu'st be changed to include polled vip tables. A new core 
image must then be generated to replace the previous one. ~For further details, 
see Section 6 ("FNP Core Images") and the description of the bind fnp command in 
Section 7. 



Definition of Polled VIP Channels 



A channel must be defined in the Channel Master File (CMF) for each terminal 
subsystem, i.e., for each polled VIP communications line connected to Multics. 
This channel is known as a multiplexer channel because it connects the entire 
subsystem. For each station in the subsystem, another channel must be defined 
in the CMF. These channels are referred to as subchannels of the multiplexer 
channel. A sample excerpt from the CMF is shown below in which a multiplexer 
channel and various subchannels are defined. For a complete description of the 
CMF, see Section H. 
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name: a.h005; 
baud: 2400; 
dataset: 201C; 
line type: POLLED^VIP; 
servTce: multiplexer; 
multiplexer type: vip7760; 
terminal_type: VIP7700_CLUSTER ; 

name: a .h005.d00-a .h005.d01 ; 
attributes: dont read answerback; 
service.; login; ~ 
terminal_type : VIP7705; 

name: a.h005.p01; 
service: slave; 
baud: 1200; 

terminal type: VIP771'4; 



The above example shows a polled VIP multiplexer with three subchannels: 
two displays and one printer. It is essential that the line type and multiplexer type 
be specified as shown. The multiplexer type of vip7760' is used generically for 
all polled VIP multiplexer channels. It does not imply that the subsystem must 
be a VIP7760. The terminal type of the multiplexer channel distinguishes the 
different types of subsystems'. More will be said about this later. 



The names of subchannels are chosen according to specific rules. The final 
component of the subchannel name must be exactly three characters. The first 
character must be "d" for a keyboard/display station, "p" for a printer station, 
or "x" for a transparent communications channel using the polled VIP protocol. 
The last two characters represent the station poll address. Note that a 
keyboard/display station can share the same poll address with a printer station. 



A baud rate should be specified for printer subchannels to distinguish 
between 300 and 1200 baud printers. 



Printer subchannels should not be defined for a VIP7804 subsystem. On the 
VIP7804, a printer is treated as a peripheral device of the keyboard/display 
station to which it is connected. The printer can only be addressed by the use 
of escape sequences within the text sent to the keyboard/display station. Therefore, 
VIP780M printers cannot be supported as independent subchannels. 



Multiplexer Terminal Types 



All terminal types, including multiplexer terminal types, are defined in 
the Terminal Type File (TTF) . The standard Multics TTF contains three polled 
VIP multiplexer terminal types that correspond to three different subsystems: 

VIP7700 CLUSTER 

VIP7804~CLUSTER 
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The differences among polled VIP subsystems have been categorized according 
to a set of parameters that control the behavior of the polled VIP multiplexer 
software within the Multics Communication System. The additional info field of 
the multiplexer terminal type is used to specify the values of thele parameters. 
This field is formatted as a character string containing a sequence of parameter 
assignments separated by spaces. Each parameter assignment has the following 
form : 

<parameter_type>= <par ameter_value> 

A sample multiplexer terminal type would appear in the TTF as follows: 
terminal_type : VIP7700_CLUSTER ; 

additional_info : "controller_poll=no quit=q formfeed=l"; 

Default values apply to any parameters not specified or to all parameters 
if no terminal type is specified. The complete set of parameters is described 
below. 

name: controller poll 

values: yes, no 
default: no 

meaning: if yes, indicates that the subsystem responds to a controller 
poll. 

name: crlf echo 

values: yes,~no 
default: no 

meaning: if yes, indicates that Multics echoes a carriage return/linefeed 
sequence after each input message is received. 



name : 
values : 
default 
meaning 



name : 
values : 
default 
meaning 



omit nl 
yes ,~no 
no 

if no, Multics appends a newline character to the end of each 
input message. 

omit_ff 
ye s , no 
no 

if no, Multics sends a formfeed character to clear the screen 
before resuming output after an end-of-page condition. 



name: gcos break 

values: yes,~no 
default: no 

meaning: if yes, Multics recognizes an input message containing the string 
$*$BRK as a quit indication. 



name: etb_mode 
values: yes, no 
default: no 

meaning: if yes, Multics terminates partial 
the terminal with an ETB character 
This ensures that escape sequences 
are correctly interpreted by the terminal, 
does not support etb mode.) 



message 
instead 



blocks transmitted to 
of an ETX character, 
that are split across blocks 
(Note: The VIP7700 



name: pause_time 

values: integer N where N >= 0 

default: 1000 

meaning: specifies the pause time in milliseconds between consecutive poll 
cycles . 
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name: max text len 

values: integer TI where 508 <= M <= 1920 
default: 1024 

meaning: specifies the maximum number of data characters in any message 
transmitted by Multics to the terminal. 



name : 
values : 
default 
meaning 



name : 
values : 
def aul t 
meaning 



name : 
values : 
default 
meaning 



max message_len 

integer N where 73 <= N <= 1024 
289 

specifies the maximum number of characters expected in an input 
message from J^^^^ This parameter is normally not specif ied 

exceiat on channels used for Levei-6 file transfer. 

quit 

any single ASCII character 

q 

when this character appears in the first function code position 
of an input message, it indicates a quit. 

formfeed 

any single ASCII character 
1 

when this character appears in the first function code position 
of an input message, it indicates a formfeed operation. 



Subchannel Terminal Types 



Terminal types for polled VIP subchannels are specified in exactly the same 
way as terminal types for ordinary asynchronous channels. The standard TTF 
contains three terminal types that apply to polled VIP keyboard/display subchannels: 

VIP7705 /* VIP7700 display with upper/lower case */ 
VIP7760 /* VIP7760 display */ 
VIP780M /* VIP7804 display */ 



Printers for polled VIP subsystems are one of two basic types: TermiNet 
or Rosy. The standard TTF contains two corresponding terminal types named TN300 
and ROSY. Also, a VIP7714 terminal type is defined that is essentially equivalent 
to TN300. 



For keyboard/display stations used as login terminals, the CMF subchannel 
entry should specify the appropriate terminal type. For slave subchannels (normally 
printers), the terminal type must be set after the device is attached. 



Input Size Considerations 



A single transmission from a polled VIP terminal can contain any number of 
characters and any number of lines ^ In the normal case, Multics expects to 
receive exactly one line with each transmission. When page-length mode is enabled, 
Multics counts each separate transmission as one line of input. Therefore, if 
more than one line is actually sent, Multics miscalculates the true cursor position. 
This can cause subsequent output to be improperly formatted. Therefore, normal 
use of a VIP7700 or VIP7760 terminal requires pressing the transmit key at the 
end of each line of input; the return key is not used. On the VIP7804, a mode 
of operation called "transmit on return" is provided that causes each line to be 
transmitted when the return key is pressed. This mode is recommended and its 
use is assumed in the discussions that follow. 
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If page-length mode is disabled for some special purpose, e.g.i a forms 
processing application, the single-line input restriction can be ignored. In 
this case, there is no problem in transmitting multiple lines or an entire 
screen. 



Polled VIP terminals (or subsystems) have a strapping option that limits 
the maximum transmission block size to 256 data characters. Larger transmission 
requests are divided into a sequence of blocks. Multics expects this option to 
be selected and rejects input blocks containing more than 256 data characters, 
unless the max message len parameter (above) is specified. 



Function Codes 



Function codes are ordinary characters that occupy a special position within 
the polled VIP message structure. Each time a polled VIP terminal transmits a 
message to Multics, the message contains two function codes. On the VIP7700 and 
VIP7760, these function codes can be set from the keyboard by pressing the 
control (CTL) key in combination with a regular key. On the VIP7804, function 
codes are generated only by the 12 special-function keys at the top of the 
keyboard . 



Multics uses the first function code in a message as a means for indicating 
a quit or formfeed operation. This is necessary because the normal mechanisms 
for indicating these operations are not available. Like most other synchronous 
terminals, a polled VIP terminal does not transmit a line break and, consequently, 
does not have a break key. Also, a polled VIP terminal does not transmit certain 
ASCII control characters including formfeed. 



The transmission of function codes varies from one terminal to another. On 
the VIP7700 and the VIP7760, function codes, like data, are not transmitted 
until the transmit key is pressed. The VIP7700, however, does not transmit a 
function code unless data has been entered. Therefore, a VIP7700 user must type 
a data character in order to send a function code. Multics ignores any data 
that arrives in the same message with a recognized function code. The VIP780i| 
is very different: when a special function key is pressed, a message containing 
a function code is transmitted automatically without any need to press the transmit 
key. 



QUITS 



As mentioned above, a polled VIP terminal does not have a break key. Therefore, 
a function code is used to indicate a quit. On the VIP7700 and VIP7760, the 
quit function code is normally "q". This code is generated by simultaneously 
pressing the control key and the Q key. On the VIP780M, the quit function code 
is normally an underscore ( ). This code is generated by simultaneously pressing 
the shift key and the F12 Tunction key. The quit function code can be changed 
by use of the quit parameter described earlier. 



Since a quit discards output that has already been formatted by Multics, 
the cursor position computed by Multics is made invalid. This can cause subsequent 
output to be improperly formatted. Therefore, whenever a user issues a quit 
while output is pending, the user should next issue a formfeed to resynchronize 
Multics with the true cursor position. Normally, this is only necessary if the 
user quits while at end of page. 



A-14 



CC75-01 



FORMFEEDS 



As mentioned above, a polled VIP terminal does not transmit a formfeed 
character. Therefore, a function code is used to indicate a formfeed operation. 
On the VIP7700 and VIP77&0, the formfeed function code is normally "1". This 
code is generated by simultaneously pressing the control key and the L key. On 
the VIP78O45 the formfeed function code is normally a circumflex C). This code 
is generated by the F12 function key (unshifted). The formfeed function code 
can be changed by use of the formfeed parameter described earlier. 



The formfeed function code is used to request Multics to clear the screen. 
This is often done before executing a command that produces a full page of 
output to avoid dividing the output between two pages. Although the user can 
clear the screen locally by use of the clear key, Multics is unaware of the 
change in cursor position. This causes subsequent output to be improperly formatted. 
Therefore, it is recommended that the clear key not be used. 



End Of Page 



Normal use of a polled VIP terminal requires that page- length mode be 
enabled. When an end-of-page condition is encountered, the resumption of output 
can be requested in several different ways. One way is to send a formfeed 
function code. Unfortunately, function codes are not especially convenient to 
send on the VIP7700 or VIP7760 (several keystrokes are required). Since the 
end-of-page condition occurs often in normal use, a more convenient method of 
resuming output is provided. 



When at end of page, the transmission of any message to Multics is construed 
as a request to resume output. Therefore, on the VIP776O, a user need only 
press the transmit key. This sends an empty message to Multics. The VIP7700, 
however, does not transmit an empty message . Therefore, at least one data character 
must be typed. The commercial-at sign (§) is used for this purpose. When at 
end of page, if Multics receives a message containing only the character, 
output is resumed and the message is discarded. If the message has any other 
contents, it is treated as normal input, and output resumes. 



On the VIP7804, one can use either the return key or the formfeed function 
key to resume output. 



Blank Lines 



Typing a blank line requires merely pressing the transmit key on the VIP7760 
or the return key on the VIP780M. The VIP7700, however, does not transmit a 
blank line; on this terminal it is necessary to type a space before pressing the 
transmit key. 



Tabs 



Use of the tab key on a polled VIP terminal produces different effects from 
an asynchronous terminal. As with most buffered terminals, a tab is converted 
to the appropriate number of spaces when displayed on the screen. These spaces 
are what eventually get transmitted to Multics. Hence, a polled VIP terminal 
never transmits a tab control character. 
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An exception arises when a user types a tab at the beginning of a line. In 
this case, the tab is interpreted not as a shorthand for spaces, but rather as a 
shorthand for moving the cursor right. The difference is that no space characters 
are entered on the screen, and, therefore, no spaces are transmitted. If the 
user really wants spaces, the problem can be avoided by always typing a space 
followed by a tab when at the beginning of a line. 



In order to create and edit text containing tabs, it is necessary for a 
polled VIP user to type an escape sequence that Multics translates into a tab 
character . Normally, the backslash h (\h) sequence is used to represent a horizontal 
tab. This sequence is defined by the special-characters table associated with a 
given terminal type. 



Circumflex and Tilde 



On the VIP7700 and VIP7760, the circumflex (") and tilde (") characters 
have special interpretations. The circumflex character causes blinking of 
subsequent characters on the same line, up to the first space. The tilde character 
causes blanking of subsequent characters on the same line, up to the first 
space. Multics, however, attaches no such special interpretation to these 
characters. Therefore, when Multics transmits these characters to the terminal, 
it is necessary to represent them without producing the blinking or blanking 
effect. 



On the VIP7760, this is accomplished by immediately following each circumflex 
or tilde with a space. This same technique cannot be used on the VIP7700 because 
it does not display the circumflex or tilde. Therefore, on the VIP7700, a 
circumflex is represented by the backslash minus sign (\-) sequence and tilde is 
represented by the backslash equal sign (\=) sequence. These sequences can also 
be typed as input on both the VIP7700 and VIP7760. 



Dialups and Hangups 



Individual stations on a polled VIP Subsystem do not "dial up" or "hang up" 
a communications line as do ordinary terminals. Therefore, these actions are 
simulated to some extent. At the time a subsystem is initialized, all slave 
subchannels are assumed to be dialed up, and all login subchannels are assumed 
to be hung up. To dial up a keyboard/display station, a user must send an input 
message of any kind. This message is discarded by Multics, but causes a simulated 
dialup to occur. Multics responds by sending a greeting message to the station. 
The user can then log in as usual . 



There is no way to produce a hangup condition from a polled VIP station. 
Switching off power to the station has no effect. Therefore, the only way to 
terminate a Multics session is by use of the logout command. After logout, a 
station reverts to the hung-up state. To begin a new session, the dialup and 
login procedure is repeated as described above. 



ADMINISTRATION AND USE OF SOFTWARE-SIMULATED TERMINALS 



Multics provides support for software-simulated terminals. These are "pipes" 
with simulated Multics terminal interfaces at either end. In the usual case, 
one end is configured as an autocall channel and the other as either a login or 
si ave channel . 
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Definition of Software Terminal Channels 



Software terminals, like all other communications channels, are defined in 
the Channel Master File ( CMF) . An entry must be made in the CMF for the 
software terminal facility, itself, as well as two for each pipe to be defined. 
A sample CMF excerpt is shown below. 



name: sty; 

service: multiplexer; 

mul t Ipl ex er_ t y pe : sty ; 
name : sty .slogin_001-sty .slogin_020; 

service: login; 
terminal_type ; STY; 

name : sty ,sslave_001-sty .sslave_005; 

service: slave; 
terminal_type : STY; 

name: sty .ulogin_001-sty .ulogin_020 ; 

service: autocall; 
terminal_type : STY_USER; 

name : sty .uslave_001-sty .uslave_005; 

service: autocall; 
terminal_type : STY_USER; 



/* entry for facility */ 



/* entry for server side 
of login channels */ 



/* entries for server 
slave channels */ 



/* entries for user side 
of login channels */ 



/* entries for user sides 
of slave channels */ 



The above configuration defines a system with 20 software terminals for 
login service and five for slave service. Each one has two channels associated 
with it, the "server" and "user" sides. The server and user sides must have the 
same name, except for the first character of the last component, which should be 
"s" for servers and "u" for users. 



If you type ahead on a login service channel that expects an answerback, 
the typed-ahead data is interpreted as the answerback string, causing STY to be 
hung up. You can avoid this circumstance by specifying the dont_read_answerback 
attribute for the login STY. 



Multiplexer Terminal Types 



The terminal types associated with software terminals (STY and STY_USER) 
define the conversions appropriate to these channels. 



Use of software- simulated terminals is incompatible with the access 
isolation mechanism (aim) . 
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SPECIFICATIONS FOR AND ADMINISTRATION OF X .25 NETWORK CONNECTIONS 



The Multics Communications System provides support for a connection to a 
packet switching network through an interface complying with 1980 CCITT 
Recommendation X.25. The networks certified for use include TYMNET, DATAPAC, 
TELENET, and UNINET. 



The Multics Communications System contains a multiplexing mechanism that 
allows each logical channel through the network to be independently controlled. 
In this manner, it is possible to configure some logical channels as login 
terminals, while others may be used for outgoing access. 
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Hardware Requirements 



The X.25 interface runs only on a DCU6661 FNP with at least 64K words of 
memory. Each separate X.25 connection requires an HDLC interface feature. Those 
supported are: 

• DCF6620 0-9600 bits/sec V.24 interface (RS232-C) 

• DCF6623 0-72000 bits/sec V.35 interface 

• DCF6622 0-72000 bits/sec Bell 3XX interface 



Software Support 



The X.25 communications protocol is an international standard that defines 
an interface to various public data networks. The information below describes 
various aspects of the X.25 interface as implemented on Multics systems. It is 
assumed that the user is familiar with the terminology used in defining the X.25 
international standard. 



LINK LEVEL (X.25 LEVEL 2) 



Both the LAPB and LAP link-level procedures are supported. Multics can act 
as either a DTE or DCE. The link-level parameters can be controlled on a per-link 
basis as follows: 

Timer (T1) 0-51.1 sec in units of .1 sec. 

Timer (T3) 1-511 sec 

Maximum Number of Transmissions (N2) 1-511 

Maximum Number of Bits in an I Frame (N1) 24-8232 in multiples of 8 bits 
Maximum Number of Outstanding I Frames (k) 1-7 



The link-level parameters are specified in the additional_info keyword used 
with the TTF entry for X.25 channels. See "Terminal Type File" below. 



PACKET LEVEL (X.25 LEVEL 3) 



Permanent Virtual Circuit and Datagram service are not supported. Up to 
4095 virtual circuits can exist. A "virtual circuit" is the equivalent of a 
logical channel. The maximum User Data field length can be any of 64, 128, 256, 
512, and 1024 octets and must be the same for all virtual circuits. The window 
size can be chosen from 1-7 and must be the same for all virtual circuits. User 
Data field length and window size are defined in the additional info keyword 
used with the TTF entry for Xc25 channels. See "Terminal Type Fiie"^ below, use 
of the More Data Mark (M bit) is not supported. Use of the Qualifier (Q) bit 
other than by X.29 is not supported. The following Optional User Facilities are 
not supported: 

• Extended Packet Sequence Numbering 

• Packet Retransmission 

• Closed User Group 
♦fr • RPOA Selection 

• Flow Control Parameter Negotiation 

• Throughput Class Negotiation 

• Fast Select 
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TERMINAL CONTROL LEVEL 



In general, the terminal control protocol described by the 1980 CCITT 
recommendations X.3 and X.29 is supported. The X.3 parameters supported and 
corresponding Multics terminal modes are described below. (Multics terminal 
modes are specified as part of the TTF entry used to define each terminal. See 
the Programmer's Reference Manual for a description of the TTF.) 



1 PAD recall by escaping from the data transfer 

state 

2 Echo 

3 Selection of data forwarding signal 
^ Selection of idle timer delay 

5 Ancillary device control 

7 Selection of operation of PAD on receipt of 

break signal from the start-stop mode DTE 

8 Discard output 

12 Flow control of the PAD by the start-stop 

mode DTE 

13 LF insertion 



rawi 

echoplex 

always set to 126 
breakall 
if low 
hndlqui t 

used by interrupt procedure 
of low 

If echo 



In addition, the following DATAPAC national parameters are supported: 



125 Output pending timer 

126 LF insertion 



polite 
If echo 



Implementing an X .25 Capability on Multics 

In order to obtain an X.25 capability on Multics, the user must: 

1. Add appropriate X.25 software to the FNP. 

2. Define the X.25 connection (physical channel) and the various terminals 
to be associated with the channel. 

3. Install a specially defined Terminal Type File (TTF). 
A description of each procedure is listed below. 



THE FNP CORE IMAGE 



Support of an X.25 connection on Multics requires that the software module 
"x25_tables" be present in the FNP core image. To accomplish this, the bindfile 
must be changed to include x25_tables, and a new core image must be generated. 
For further details see Section 6 ("FNP Core Images") and the description of the 
bind fnp command in Section 7. 
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DEFINITION OF X.25 CHANNELS 



One channel must be defined in the Channel Master File (CMF) for each X.25 
network connection. Appropriate subchannels must be defined for each terminal 
to be associated with the multiplexed channel. A sample CMF follows. 



name: b.hl02; 
baud: 9600; 
line type: X25LAP; 
servTce: multiplexer; 
multiplexer_type : x25; 
terminal_type : X25_DATAPAC; 

name: b.h102.001-b.h102.050; 
service: login; 
terminal_type : ASCII; 

name: b .hi 02 . 051 -b .h102. 063 ; 
service: autocall; 
terminal type: none; 



The above configuration defines a connection to the network at 9600 baud 
through channel b.h102. Multics will behave as the DTE (the default type) and 
will use the basic X.25 protocol. There are 50 inward (login) channels and 13 
outward channels. 



TERMINAL TYPE FILE (TTF) 



The user must install a specially defined TTF to support the X.25 facility. 
The TTF must contain a site-specific entry for the X.25 connection. Examples of 
entries for TYMNET and DATAPAC are supplied in the TTF shipped with the system. 



The only portion of the TTF entry that is used is the "additional_info" 
keyword. The character string is used to specify the value of various parameters 
used to control multiplexer operation. The parameters are all optional except 
"n_lc," which must be specified. The field is formatted as a series of parameter 
assignments, separated by spaces. 



A sample TTF entry for a X.25 multiplexer might appear as follows: 

terminal_type: X25_TYMNET 

additional_info : "network= tymnet n lc=32 packet_size= 1 28 window_size=2 
type=DTE 1 ink_proYocol=LAP fr ame_size=8232 T1=3 N2=20 
T3=3 K=7"; 



The complete set of parameters is listed below: 

name: type 

values: DTE, DCE 

default: DTE 

meaning: specifies whether the Multics system behaves as the DTE or DCE. 



name: 1 ink_protocol 

values: LAP, LAPB 

default: LAP 

meaning: connection mode is either LAP or LAPB (Balanced). 
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name: disc_first 
values: yes, no 
default: no 

meaning: specifies whether Multics enters the DISC SEND state. This 
should only be used for networks implementing the old TELENET 
X.25 protocols. 

name: frame_size 

values: 24 through 8232 in multiples of 8 
default: 1064 

meaning: specifies the maximum size, in bits, of transmitted frames. This 
size must be -large enough to contain a packet whose length is 
packet__sire (see below) plus the level 3 header (3 or 4 
characters) . 



name: 
values : 
default 
meaning 



K 

1 through 7 
7 

specifies the 
allowed . 



number of outstanding unacknowledged frames 



name: N2 

values: 1 through 511 

default: 20 

meaning: specifies the number of times a frame is retransmitted before the 
link is reset. 



name: T1 

values: .1 through 51.1 (in tenths of a second:) 
default: 3.0 

meaning: specifies the time, in seconds, to 
acknowledgement . 



wait for a frame 



name: T3 

values: 1 through 511 

default: 3.0 

meaning: specifies the number of seconds to wait for a response to a link 
reset. 



name: packet__size 
values: 64 through 1024 
default: 128 

meaning: specifies the maximum number 
transmitted in a single packet. 



of octets (characters) to be 



name : 
val ues : 
default 
meaning 



name: 
values : 
default 
meaning 



collect 
yes, no 

no 

specifies that all outgoing calls from a given x.25 multiplexer 
are to be made collect; i.e., the receiving system is to pay the 
network charges. 

packet_threshold 
2 through 1025 
packet_size+1 

specifies the minimum length of a "long packet" . The multiplexer 
will not output a long packet if there are any short packets 
queued for output. The effect of this is to optimize the 
transmission of short packets such as might be used to echo 
character-at-a- time input. The default value of one greater than 
the maximum packet size has the effect of disabling the 
preferential treatment of short packets. 

For example, if a number of Emacs users are sharing a network 
connection with an output- intensive application such as Inter- 
Multics File Transfer, the site may want to set the packet 
threshold to a small value in order to give the 1- to 3-character 
packets used to echo input priority over the large packets 
generated by the file transfer application. 



12/83 



A-21 



CC75-01B 



name: window_size 
values: 1 through 7 
default: 2 

meaning: specifies the window size W to 
network. 



be used in communicating with the 



name: local_address 

values: 1 to 15 decimal digits 

default: none 

meaning: specifies the local address to be used in call request packets. 

This parameter has no default value; if no value is specified, 
none is used. 

name: network 
values: tymnet, datapac 
default: none 

meaning: specifies which set of national parameters will be assumed. This 
parameter has no default value; if no value is specified, none is 
used . 



name: n_lc 

values: 1 through 4095 

default: none 

meaning: specifies the number of X.25 logical channels to be defined. 
This parameter has no default value and must be specified. 

name: d_bit 
values: yes, no 
default: yes 

meaning: specifies whether the network supports the use of the D bit for 
end-to-end acknowledgement. 



CONNECTING TO A FOREIGN SYSTEM THROUGH A PROTOCOL CONVERTER 



A user logged into Multics on an asynchronous terminal can talk to a 
foreign system by attaching to a protocol converter through subchannels on an 
FNP. Any incompatibilities between the terminal type and the foreign system are 
made transparent by the protocol converter. For example, the Renex Protocol 
Converter, Model RT9B, manufactured by the Renex Corporation of Springfield, 
Virginia, can be used to connect Multics to an IBM system, by simulating a 3270 
terminal controller. 



The connection is made through the services of the dial_out facility, by 
specifying either the dial_out or connect command to a generic destination, 
thereby causing a pr iv ileged_attach of a slave channel with a matching 
destination. Alternatively, a dial out over an autocall channel can be 
effected, but this requires that a specific destination be supplied. The 
dial_out and connect commands are described in detail in the Commands manual. 
The generic destination statement is part of the CMF channel entry (see below). 



Once the connection is established, data transmission may commence between 
the two nodes at a speed appropriate to the configuration (i.e., the FNP and the 
protocol converter in use) . A wait request is available for use with dial_out 
exec__coms, which allows for synchronization of transmissions from the foreign 
system (see the description of the dial out command in the Commands manual) . 



Channel Definition for Foreign System Connections 



Typically, a number of channels are hardwired between the Multics FNP and 
the protocol converter. Their CMF entries include a gener ic_destination 
statement to be specified in the dial out command. A sample excerpt from the 
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CMF is shown below; note that the channel -names can be arbitrary. For a 
complete description of the CMF, see Section U, 

name: a.h006; 
terminal_type : ascii; 
baud: 9600; 

attributes: hardwired, dont__read_answerback; 
gener ic_destination : IBM1 ; 
service: slave; 

comment: "connection to IBM system through Renex protocol converter"; 

name: b.h102; 
terminal_type : ascii; 
baud: 9600; 

attributes: hardwired, dont_read__answerback; 
generiG_destination : IBM1 ; 
service: slave; 

comment: "connection to IBM system through Renex protocol converter"; 

This excerpt defines two channels connected to an IBM system through a 
Renex protocol converter that simulates a 3270 terminal controller. By entering 
the dial out command to the generic destination (dial_out IBM1), the user can 
attach wHichever line is available to communicate with the IBM system. 



Mapping the Terminal Type to the Foreign System 



Sometimes the channel requires special initialization before communication 
can be established (this usually depends on the compatibility between the 
terminal type and the foreign system). Thus, a protocol converter commonly 
determines the user' s terminal type so that any necessary mapping of terminal 
functions can be performed before the connection is established. 



When terminal conditioning is required, the user enters the connect 
command, rather than the dial out command, to the generic destination (connect 
IBM1 , for the excerpt aboveT, which automatically executes a site-supplied 
dial out exec com (IBMI.dial out, in this case) to perform the appropriate 
startup functTons. The connect command bypasses any existing user dial_out 
start_up exec_com, searching the dial_out search list as follows: 

-working_dir 

>udd>[user project]>dial_out_dir 
> site> dial_out_dir 

A sample dial_out exec_com to start up communications on a line attached 
through a Renex protocol converter is shown below. 

&version 2 
&trace off 
&- 

&- Translate terminal type to Renex terminal type number. 
&- If the terminal type is not supported by Renex, 
&- generate XX for the terminal number. 
&- 

&set renex type 
&+ &[e "Before 

&+ &[e after 

&+ : VIP7200:03: VIP7201 :03:VIP7205:03:VIP7801 :03 

&+ : VIP7803 : 03 : VI P7804 : 03 : ADM3A : 06 : HAZELTINE 1 500 : 02 
&+:HP2621 :09: IBM3101_1X:01 : IBM31 01_2X: 0 1 : TV1 920 : 05 
&+:TV1950:05: VT52:01 :VT100:01 : [e user term_type] :XX: 
&+ :[e user term type]: ] 
&+ :] 

&- 

&- Wake up Renex converter. 
&- 
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send \015 
&- 

&- If the terminal number is XX, display the Renex 
&- terminal menu and let the user decide what to do. 
&- 

&if &[e equal &( renex_type) XX] &then &quit 

&else &do 

&- 

&- User terminal type is known. Discard the Renex menu 
&- and tell the Renex converter what the terminal is. 
&- 

. .f ile_output [pd]>&! 

wait "ENTER TERMINAL NUMBER, 2 DIGITS." -time 20 

..ro; dl [pd]>&! 

send &( renex_type) 
&end 
&quit 
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APPENDIX B 



MU-LT I C-S -COMMU-WIG AT-ION S YSTEM • -M EMO-R Y CO-NF I CU R ATOR 



This appendix provides a Multics Communication System memory configurator 
which can be used to approximate maximum memory utilization on the DN355, DN6632, 
and the DN6670 front end processors. 



The calculations outlined in Steps 1 through 5 apply only to FNPs configured 
for 32K of memory. 



The calculations outlined in Steps 6 through 11 apply only to a DN6670 
configured with at least 64K of memory. 



Many terms and mechanisms that are referred to in this appendix are described 
in the Multics Communications System manual (Order No. AN85). 



FNP CONFIGURED WITH 32K OF MEMORY 



1. Table 1 lists those modules that are required to be in the image. 
Also included is the memory required to support the lOM table and 
interrupt vectors. The init module is released for buffer space at 
the end of FNP initialization and is not to be included in the total 
count. The FNP requires around 30 buffers for DIA queues and other 
support operations and this is included in the minimum buffer pad 
entry. 



TABLE 



1 



MODULE 



LENGTH 



TOTAL 



control_tables 

dia_man 
interpreter 



1806 

3U04 
1Q86 



1806 
3U04 
1986 



util ities 

minimum buffer pad 
interrupt vect 
iom tables 
init 



2612 
960 
512 



32 
360it 



1 332 
2612 
960 
512 
32 



SubTotall 
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Table 2 lists the modules that a site may optionally configure based 
on the CDT and other site requirements. Refer to Section 6 of this 
manual for details of when one of these should be included. Sum the 
TOTAL column and enter result in the box after SubTotal2. 



TABLE 2 



MODULE LENGTH TOTAL 



1 acu tables 


1121 1 


1 ards tables 






1 autoBaud tables 


252 




1 breakpoint man 


220 




Ibsc tables 


2358 




iCon"sole man 


me 




Ig115 tables 


1884 




! ibm3270 tables 


616 




1 ic sampTer 


2090 




! hsTa man 


3838 




! Isla man 


1872 




1 meters 


112 




1 polled vip tables 


1258 




1 printer trace 


1208 




! t202_ta¥les 


5M6 




lhasp tables 


980 




1 trace 


546 




1 trace buffer 






Ivip tables 


532 




SubTotal2 





Table 3 determines the amount of memory required to support the various 
types of channels and devices. Echoplexed channels for this discussion 
are those which use any one of the following modes: echoplex, crecho, 
Ifecho, or tabecho. A blank is provided in the table to enter the 
number of each type of channel or device. Multiply this number by the 
number in the third column and place result in fourth column. Sum the 
entries in the "memory required" column and enter result in the box 
after SubTotal3. If metering is enabled, an additional 42 words is 
required for each channel. 



NOTES: On the line labeled "LSLA device", enter the number of LSLAs 
configured on the FNP. 

On the line labeled "HSLA device", enter the number of the 
HSLAs configured on the FNP. 

The following abbreviations are used below: 

TIB = terminal information block 

TB tbl = TIB table entry 

TB ext = TIB extension buffer 

SFCM = software communications region 

10 buf = input, output, and echo buffers 

JP tbl = jump table 

HSLA = high speed line adapter 

LSLA = low speed line adapter 
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TABLE 



3 



type of channel 



number 
channels X 



memory/ 
channel 



memory 
required 



non echoplexed LSLA 




124 


(1) 


echoplexed LSLA 




156 


(2) 


non-echopl exed tty HSLA 




178 


(3) 


echoplexed tty HSLA 




210 


(4) 


gl15 protocol 




552 


(5) 


polled vip protocol 






(6) 


ibm2780 protocol 




51^ 


(7) 


ibm3780 protocol 




514 


(8) 


HASP protocol 






(9) 


LSLA device 




IFB 


(10) 


HSLA device 




97 


(11) 



Legend: (1) = 



Legend: (3) = 



Legend: (5) = 



SubTotal3 




TIB 


42 


Legend: (2) = 


TIB 


42 


TB tbl 


2 




TB tbl 


2 


10 buf 


80 




10 buf 


112 




124 






156 


SFCM 


54 


Legend: (4) = 


SFCM 


54 


TIB 


42 




TIB 


42 


TB tbl 


2 




TB tbl 


2 


10 buf 


80 




10 buf 


112 




178 






210 


SFCM 


54 


Legend: (6) = 


SFCM 


54 


TIB 


42 




TIB 


42 


TB tbl 


2 




TB tbl 


2 


TB ext 


16 




TB ext 


24 


10 buf 






10 buf 


See 










*lfote 1 




552 









NOTE 1: The size in words of one VIP7760 I/O buffer is controlled by the 
max message_^len specification in the TTF entry for the multiplexer. The 
following accounts for three buffers: one output and two input. 

(max^i»essage_^len/2 + 2)*3 

Enter the above result into "10 buf." 



Legend: (7) = 



Legend: (9) = 



SFCM 


54 


Legend: (6) : 


: SFCM 


54 


TIB 


42 




TIB 


42 


TB tbl 


2 




TB tbl 


2 


TB ext 


32 




TB ext 


32 


10 buf 


384 




10 buf 


384 




514 






514 


SFCM 


54 


Legend: (10) : 


: SFCM 


38 


TIB 


42 




10 buf 


128 


TB tbl 


2 








TB ext 


32 






166 


TB buf 


See 










Tote 2 
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Legend: (11) = JP tbl 97 

97 



NOTE 2: The size in words of one HASP I/O buffer is expressed by 
2 + block_size/2 

where there are two words of buffer overhead and block_size is specified 
by the TTF entry of the multiplexer. Enter the above result into "10 
buf ." 

I 1/0 Buffer Value for FNPs Configured with 32K of Memory 



The above HSLA asynchronous I/O buffer entries include two mini-buffers for 
input. Each mini-buffer is eight words long to hold ^^ characters and one word 
for housekeeping. These entries do not apply to those channels which operate in 
block transfer mode. Two input buffers are assigned to each channel in block 
transfer mode. The length of each buffer is set to hold at least 0.1 second of 
transmission (in whole 32-word blocks). A 32-word buffer speeds up to M800 
baud, 6M-word buffer to 9600 baud, etc. 



Only one input buffer is assigned on LSLA channels when the first character 

of a line is received. The value used (16 words) for the LSLA I/O buffer 

entries assumes that half of the LSLA channels have received input which is less 
than 60 characters. 



All asynchronous channels are given two output buffers in the above I/O 
buffer entries. It has been shown that an FNP running with all channels generating 
traffic services all channels smoothly if two output buffers are assignable to 
each asynchronous channel. 



An echo buffer of 32 words is assigned to each channel that is operating 
with any of the following modes turned on: echoplex, crecho, Ifecho, or tabecho. 



i\. Calculate the sum of SubTotall, SubTotal2, and SubTotal3. Subtract 
this sum from 32768. The result is the amount of free buffer space. 

5. It is possible that there may not be enough memory available during 
FNP initialization. This occurs while init is still executing and 
allocating TIBs and SFCMs . Table M and Table 5 help determine if too 
many channels are configured given the core image size in SubTotall 
and SubTotal2. 



Enter the appropriate numbers into the "number channels" column. Perform 
the multiplication and enter the results into the "memory required" 
column. Sum the "memory required" column and enter the result into 
the box after SubTotal4. 
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TABLE 



type of channel 



number memory/ memory 
channels X channels = required 



iLSLA device (<6) 
ILSLA channels 
IHSLA device (<3) 
iHSLA channels 



42 
97 
96 



SibTotilT 



If there are no LSLA devices configured, strike out the "LSLA 
initialization code" entry in Table 5, since the code to initialize 
LSLA devices is released prior to TIB and SFCM allocation. 

Insert the previously determined values for SubTotall, SubTotal2, and 
SubTotal4. 



i SubTotall 

! SubTotal2 

I SubTotal4 

I basic size of init 

I LSLA initialization code 



If SubTotal5 is over 32768, FNP initialization fails. If it is close, initialization 
may fail. This depends on where buffer boundaries are in relation to the boundaries 
of the executable code that is released in the init module. 



DN6670 CONFIGURED WITH AT LEAST 64K OF MEMORY 



6. Table 6 lists those modules that are required to be in the image of a 
DN667O with at least 64K of memory configured. Also included is the 
mem.ory required to support the lOM table and interrupt vectors. The 
init module is released for buffer space at the end of FNP initialization 
and is not to be included in the total count. The FNP requires around 
30 buffers for DIA queues and other support operations and this is 
included in the minimum buffer pad entry. 



TABLE 



5 



SubTotal5 
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TABLE 6 . 



MODULE 


LENGTH 


TOTAL 


1 control_tables 


! 1840 ! 


1840 ! 


j hsla__man 


! 4568 ! 


4568 i 


1 dia_man 


1 3738 1 


3738 i 


1 interpreter 


I 2140 1 


2140 1 


1 scheduler 


1 1310 1 


1310 ! 


! util ities 


1 3370 i 


3370 1 


1 minimum buffer pad 


1 960 1 


960 i 


1 interrupt vect ' 


1 512 1 


512 1 


1 iom tables 


! 32 1 


32 1 


{paging windows 


! 512 1 


512 i 


! in it 


1 2750 1 






SubTotal6 i 


18982 ! 



7. Table 7 lists the modules that a site may optionally configure based 
on the CDT and other site requirements. Refer to Section 6 of this 
manual for details of when one of these should be included. Note that 
the trace buffer size is not included in this table. The trace buffer 
is allocated in the upper memory when 64K or more is configured. The 
maximum size of the trace buffer is determined in Step 11. Sum the 
TOTAL column and enter result in the box after SubTotal7. 



TABLE 7 



MODULE LENGTH TOTAL 



i acu tables 


128 




iards tables 


674 




I autobaud tables 


282 




1 breakpoint man 


224 




i bsc tables 


2440 




1 console man 


480 




ig115 tables 


I960 




1 ibm3270 tables 


650 




1 meters 


122 




I ic sampler 


2104 




[polled vip tables 


1384 




1 t202_tables 


546 




{hasp tables 


986 




1 x25_Tables 


4098 




1 trace 


254 




! vip_tables 


532 




SubTotal7 





i i 



8. Table 8 determines the amount of memory in the low-order 32K required 
to support the various types of channels and devices. This space is 
made up of TIB table entries and TIB extensions. Echoplexed channels 
for this discussion are those which use any one of the following 
modes: echoplex, crecho, Ifecho, or tabecho. A blank is provided in 
the table to enter the number of each type of channel or device. 
Multiply this number by the number in the third column and place 
result in fourth column. Sum the entries in the "memory required" 
column and enter result in the box after SubTotalS. Additional space 
is not required for metering in an extended memory configuration. 
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The following abbreviations are used below: 

TIB = terminal information block 
SFCM = software communications region 
HSLA = high speed line adapter 



TABLE 8 



number memory/ memory 

type of channel channels X channel = required 



1 tty 




2 




igl15 protocol 




18 




1 polled vip protocol 




26 




1 ibm2780 protocol 




34 




libm3780 protocol 




34 




IHASP protocol 




34 




IX. 25 protocol 




36 




IHSLA 




97 




SubTotalS 





Calculate the sum of SubTotal6, SubTotal7 , and SubTotal8. If it is more than 
32768, the FN? is over-configured. 



9. Table 9 determines how much space is required for I/O buffers. This 
space is allocated in extended memory. Echoplexed channels for this 
discussion are those which use any one of the following modes: 
echoplex, crecho , Ifecho, or tabecho . A blank is provided in the 
table to enter the number of each type of channel or device. Multiply 
this number by the number in the third column and place result in 
fourth column. Sum the entries in the "memory required" column and 
enter result in the box after SubTotal9. 



TABLE 9 



number memory/ memory 

type of channel channels X channel = required 



1 non echoplexed tty 
1 echoplexed tty 
1 g1 15 protocol 
ipolled_vip protocol 
1 ibm2780 protocol 
1 ibm3780 protocol 
iHASP protocol 
IX. 25 protocol 




64 
96 
438 

See Note 4 
224 
256 

See Note 5 
See Note 6 




SubTotal9 





NOTE 4: The size in words of one VIP7760 I/O buffer is controlled by 
the max_message_len specification in the TTF entry for the 
multiplexer. The following accounts for three buffers: one 
output and two input. 

(max_message_len/2 + 2)*3 

Enter the above result into the table. 
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NOTE 5: The size in words of one HASP I/O buffer is expressed by 
2 + block_size/2 

where there are two words of buffer overhead and block_size is 
specified by the TTF entry of the multiplexer. Enter the 
above result into the table. 



NOTE 6: The space required is a function of frame_size and the 
behavior of the protocol. The maximum space required is: 

I (frame__size/l6)»(K+10) 

I but the average is less than ( frame_size*1 6)/K . 



10, The TIB and SFCM for each channel are allocated in a single 256-word 
page. Meters for the channel, if metering is enabled, are allocated 
in the same page, as are the permanent input buffers for asynchronous 
channels. The remainder of the page, if any, is included in the 
buffer pool. However, for safety and simplicity, the entire page 
should be counted against the channel. The space taken up for TIBs 
and SFCMs is therefore calculated as follows: 

number of channels x 256 = SubTotallO 



256 



11. The maximum size of the trace buffer is determined as follows: 
calculate the sum of SubTotal9 and SubTotallO and add 32768. Subtract 
the result from the total amount of memory configured. This result 
(or something less) can be used after the size key-word for the trace 
module in the bindfile for the FNP core image. 
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NOTE 6: Assuming the channel is operating at 9600 baud, the number of buffers 
per frame is expressed by 

buffers per frame = frame size/406M 
(to the~nex'f whole numberj 

where the frame size (in bits) is specified by the TTF entry of the 
multiplexer. ~ 

The FNP could be holding one output frame, one input frame, and two 
input buffers. The total number of buffers involved is 

(2*buffers_per_frame + 2)*256 

Enter the above result into "10 buf 



I/O Buffer Values for a DN6670 Configured with 64K of Memory 



All the above asynchronous I/O buffer entries include two mini-buffers for 
input. Each mini-buffer is eight words long to hold ^^ characters and one word 
for housekeeping. These entries do not apply to those channels that operate in 
block transfer mode. Two input buffers are assigned to each channel in block 
transfer mode. The length of each buffer is set to hold at least one-half 
second of transmission (in whole 32-word blocks). A 32-word buffer works for 
1200 baud, G^l-word buffer for 2400 baud, and so on. 



All asynchronous channels are given two output buffers in the above I/O 
buffer entries. It has been shown that an FNP running with all channels generating 
traffic services all channels smoothly if two output buffers are assignable to 
each asynchronous channel. 



An echo buffer of 32 words is assigned to each channel that is operating 
with any of the following modes turned on: echoplex, crecho, Ifecho, or tabecho. 



9. Calculate the sum of SubTotal6, Sub Total?, and Sub Totals. Subtract 
this sum from 32768. The result is the amount of free buffer space. 

10. The maximum size of the trace buffer can be determined from how many 
channels are configured. The TIB and SFCM allocation mechanism is 
constrained to keep the TIB and SFCM for a channel in the same page 
(256-word block) of memory. This allows TIBs and SFCMs for two channels 
to be allocated in one 256-word page. The following calculation can 
be used to determine how large the trace buffer can be given the 
channel configuration of the FNP: 



number 

channels x 128 = memory 

1 TJVTJ — I 

I I ^C5 I 

I I 



The product of the above calculation is the memory required to hold 
the TIBs and SFCMs. Subtract this product from 32768 and the result 
is the maximum size of the trace buffer. This result (or something 
less) may be used after the size key-word for the trace module in the 
bindfile for the FNP core image. 
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APPENDIX C 



SPACE REQUIREMENTS IN tty buf 



Two terms are defined to help make clear the data that will be presented 
later in this section: multiplexer channel--a channel that represents a concentrator 
controlling one or more channels; subchannel--a channel that represents the user's 
terminal or end device. All channels that are not multiplexer channels are 
considered to be subchannels. 



An FNP is a multiplexer to which, for example, a VIP7P01 can be attached. 
The full name of the channel would be something like "b,h024". The parent 
multiplexer name is "b" (the FNP), and the subchannel name is "hC2il". 



DATA BASES IN tty buf 



The space used by tty buf is occupied by various data bases that are used 
to maintain proper control "of the Multics Communication Management. 



Static space is allocated in tty buf for output DCW lists for each FNP. 
This occupies 128 words for each loaded FNP (8 DCW lists * 16 words per DCW 
1 ist) . 



The logical channel table (LCT) is also maintained in tty buf. Its size is 
determined by the number of channels configured in the CMF. ""It is defined by 
the structures in the lct.incl.pl1 include file. There is a 16-word header at 
the beginning of the LCT. Each channel (m.ul tiplexer or subchannel) requires a 
32-word entry (LCTE). 



A physical channel block (PCB) is configured for each channel of each FNP 
(names that match * .* , including multiplexers, but not subchannels of mul tiplexer s) , 
eight words per channel. 



A wired terminal control block (WTCB) of 20 words is allocated in tty_buf 
for each subchannel . 



I/O buffers are dynamically created and deleted as needed. Each protocol 
makes different demands on tty_buf space. (See "Dynamic Storage in tty_buf" 
below. ) 
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STATIC STORAGE IN tty buf 



Subchannel and Multiplexer Channel Static Data Requirements 



FNP subchannels--For those subchannels of the FNP matching the star name *.* 
the following is required: 

PCB 8 

LCTE 32 

WTCB 20 

Total 60 words 



VIP7760 multiplexer — This multiplexer type requires a data base in tty buf defined 
by the "pvmd" structure in the polled_vip_mpx_data.incl.pl1 include Tile. 

PCB 8 

LCTE 32 

PVMD U8 

Total 88 words 



VIP7760 subchannel — Each subchannel of a VIP7760 type multiplexer requires a 
data base in tty buf defined by the "pvste" structure in the 
polled_vip_mpx_data.incl.pl1 include file. 

LCTE 32 

PVSTE 4 

WTCB 20 

Total 56 words 



IBM3270 multiplexer — This multiplexer type requires a data base in tty_buf defined 
by the "md" structure in the ibm3270_mpx_data.incl.pl1 include file. 

PCB 8 

LCTE 32 

MD 64 

Total 104 words 



IBM3270 subchannel — Each subchannel of an IBM3270 multiplexer requires a data 
base in tty_buf defined by the "mde" structure in the ibm3270_mpx_data . incl .pll 
include file. 

LCTE 32 

MDE 12 

WTCB 20 

Total 64 words 
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X.25 multiplexer — This multiplexer type requires a data base defined by the 
"x25d" structure in the x25_data . incl . pi 1 include file. 

LCTE 32 
X25D 32 
Total 64 words 



X.25 subchannel — Each X.25 subchannel of an X.25 multiplexer requires a data 
base defined by the "xsce" structure in the x25_data . incl . pi 1 include file. 

LCTE 32 
XSCE 1U 
WTCB 20 
Total 66 words 

X.25 logical channel--Each logical channel of an X.25 multiplexer (defined by 
the n Ic parameter) requeues a data base defined by the "xlce" structure in 
x25_dala . incl .pi 1 include file. 

XLCE 28 
Total 28 

HASP mult iplexer--This multiplexer type requires a data base defined by the 
"hmd" structure in the hasp mpx_data . incl . pi 1 include file. 

PCB 8 

LCTE 32 

HMD 56 

Total 96 words 



HASP subchannel--Each HASP subchannel of a HASP multiplexer requires a data base 
defined by the "hste" structure in the hasp mpx data. incl. pl1 include file. 



LCTE 
HSTE 
WTCB 
Total 



32 
30 
20 

82 words 
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Calculation of Static Storage in tty buf 



The following chart outlines the required data needed to find out how much 
static storage is required in tty_buf. The data is obtained from the CDT. 





memory/ 


memory 


type of channel 


number X channel : 


: required 


!tty buf header 




r 

— 


72 


iDCW lists 




128 




1 LCT header 






16 


1 spare channel count in CDT 




32 




! FNP subchannels 




60 




iHASP multiplexers 




96 




'HASP subchannels 




82 




IIBM3270 multiplexers 




104 




IIBM3270 subchannels 




6M 




1VIP776O multiplexers 




88 




IVIP7760 subchannels 




56 




IX. 25 multiplexers 




64 




1X.25 subchannels 




66 




IX. 25 logical channels 




28 




Total 





DYNAMIC STORAGE IN tty buf 



It is difficult to predict what demands the users of a system will place on 
the available I/O buffer space in tty_buf. This has to be measured with 
system_comm meters. It has been found that tty_buf should not run more than 80% 
full to handle peak loads best. 



Delay queues are also dynamically allocated in tty buf and can crash the 
system if there is no room for them. These are transactions that the host is 
requesting the FNP to perform. If there is no mailbox to put the transaction 
into, it is entered into the delay queue for later processing. 



Some comments can be made about each protocol's handling of its I/O buffer 
space in tty_buf. Only an actively operating line will require I/O buffer space 
in tty_buf. The following calculations should only be performed on the number 
of channels expected to be active at any one time. 
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Buffer Size When Controlled by Baud Rate 



The output buffer size is sometimes controlled by the baud rate of the 
channel. This occurs as noted in the following sections. 



Whether a given block of data is delivered all at once depends on the 
available space in ring 0 and in the FNP. 



At speeds of 4800 baud and below, no more than 960 characters are sent to 
the FNP at a time. However, you can adjust the baud rate FNP entry in the CMF 
(see "FNP Entries in the CMF"). When required, use the following equations to 
determine the size of the buffer. 



If the baud rate of the channel is below 1200 baud, assume it is 1200 baud 
for the following calculations. Each buffer has a one-word header containing 
the address of the next buffer and the number of characters in the buffer. 

buffer_char_size = min((6n * baud/ 1 200 ) -4 , 508) 

The following equation expresses the size of the buffer in words: 

buffer word size = buffer char size/4 



ASYNCHRONOUS I/O BUFFER SPACE 



Input buffer size is 16 words when channel is not operating in block transfer 
mode. If the channel is operating in block transfer mode, the buffers will be 
based on the baud rate of the channel. Output buffer size is based on the baud 
rate of the channel (see discussion above). The following formula accounts for 
one input buffer and one output buffer: 

JL 1 no u j-ii u±u(JK. Of dnaier iiiuucj 

ASYNC-IO r buf fer_word_size + 16 

if in block transfer mode; 

ASYNC-IO = buffer word size * 2 



G115 I/O BUFFER SPACE 



Entry in table accounts for two buffers. 



HASP I/O BUFFER SPACE 



The size of HASP buffers in tty_buf is controlled by the block_size parameter 
in the TTF entry of the multiplexer. An active HASP multiplexer will most 
likely have three blocks in tty buf: two for output and one for input. 

HASP-IO = 3 * ttf block size 
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IBM2780 AND IBM3780 I/O BUFFER SPACE 



The size of a buffer is controlled by the value following the -size control 
argument in the attach description to bisync__. The following formula accounts 
for two buffers: 

IBM2780/3780-IO = ((block size/4) + 1)*2 



IBM3270 I/O BUFFER SPACE 



Entry in table accounts for two buffers. 



VIP7760 I/O BUFFER SPACE 



The buffer size is controlled by the max_inessage_len specification in the 
TTF entry for the multiplexer. The following accounts for two buffers: 

VIP7760-IO = (max messsage len/4 + 1)*2 



X.25 I/O BUFFER SPACE 



Data is transmitted and received in frames. Each frame occupies as many 
buffers as necessary to hold the frame. The size of the frame is controlled by 
the frame size parameter specified in the TTF entry of the multiplexer. 



Buffer size for X.25 multiplexers is based on the baud rate of the channel 
(see above). The frame_size parameter in the TTF entry is used to determine the 
number of buffers that will hold the frame. 

buffers per frame = ( frame_size/8)/buf fer_char_size 
(to the~nexY whole number) 

Now the number of words used by each frame can be calculated. 

frame words = ((buffer char size/4 )+1 )*buffers per frame 



The X.25 protocol allows up to 7 frames to be transmitted before an 
acknowledgment needs to be received to send more frames. This is controlled by 
the window size parameter in the TTF entry of the multiplexer. It is possible 
that there~would be one output v.'indow v;aiting to be acknowledged plus two output 
frames being filled in by the multiplexer. Two input frames should also be 
allowed for. The total number of words for each X.25 multiplexer will be: 

X25-I0 = (window size + U)*frame words 
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Calculation of Dynamic Storage in tty buf 



memory/ memory 
type of channel number X channel = required 



1 Asynchronous I/O buffer space 




ASYNC-IO 


!G1 15 T/0 buffer space 




170 


IHASP I/O buffer space 




HASP-IO 


i IBM2T80/3780 I/O buffer space 




IBM2780/378O-IO 


!IBM3270 I/O buffer space 




130 


IVIP7760 I/O buffer space 




VIP7760-IO 


X.25 I/O buffer space 




X. 25-10 




Total 



2/83 



C-7 



CC75-01A 



MULTICS ADMINISTRATOR'S MANUAL 

COMMUNICATIONS 
ADDENDUM B 



SUBJECT 

Additions and Changes to the Manual 



SPECIAL INSTRUCTIONS 

Refer to the Preface for "Significant Changes." 

This is the second addendum to CC75, Revision 1, dated July 1982. 

Insert the attached pages into the manual according to the collating instruc- 
tions on the back of this cover. Throughout the manual, change bars indicate 
new and changed information; asterisks denote deletions. These changes will 
be incorporated into the next revision of this manual. 

Note: 

Insert this cover behind the manual cover to indicate the updating of this 
document with Addendum B. 



SOFTWARE SUPPORTED 

Multics Software Release 10.2 



ORDER NUMBER 
CC75-01B 



39104 
1183 

Printed in U.S.A. 



December 1983 

Honeywell 



COLLATING INSTRUCTIONS 



To update the manual, remove old 

Remove 

iii through vi 
vii, blank 

1- 1 through 1-4 

2- 3, blank 

4-3 through 4-6 
4-6.1, blank 
4-7, 4-8 

4- 9, blank 

5- 3, 5-4 

6- 3, 6-4 

7- 1 , 7-2 

7- 21, 7-22 

8- 11, 8-12 
A-1 , A-2 
A-5, A-6 
A-17, A-18 

A-21, A-2 2 

B-5 through B-8 

i-1 through i-4 



es and insert new pages as follows: 
Insert 

iii through vi 

1- 1 through 1-4 

2- 3, blank 

4- 3 through 4-10 

5- 3, 5-4 

6- 3, 6-4 

7- 1, 7-2 

7-21, blank 

7- 21.1, 7-22 

8- 11, 8-12 

A-1, A-2 

A-5, A-6 

A-17, blank 
A-17.1, A-18 

A-21 through A-24 
B-5 through B-8 
i-1 through i-4 



The information and specifications in this document are subject to change without notice. This 
document contains information about Hone3rwen products or services that may not be available 
outside the United States. Consult your Honeywell Marketing Representative. 

©Honeywell Information Systems Inc., 1983 File No.: 1L63, 1U63 



12/83 



CC75-01B 



MULTICS ADMINISTRATORS' MANUAL 

COMMUNICATIONS 
ADDENDUM A 



SUBJECT 

Additions and Changes to the Manual 



SPECIAL INSTRUCTIONS 

Refer to the Preface for "Significant Changes." 

This is the first Addendum to CC75, Revision 1, dated July 1982. 

Insert the attached pages into the manual according to the collating instruc- 
tions on the back of this cover. Throughout the manual, change bars indicate 
new and changed information; asterisks denote deletions. These changes will be 
incorporated into the next revision of this manual. 
Note: 

Insert this cover behind the manual cover to indicate the updating of 
this document with Addendum A. 



SOFTWARE SUPPORTED 

Multics Software Release 10.1 



ORDER NUMBER 
CC75-01A 



36095 
1282 

Printed in U.S.A 



February 1983 



Honeywell 



COLLATING INSTRUCTIONS 



To update the manual, remove old pages and insert new pages as follows 



Remove 

iii through vi 
vii, blank 

2-1, 2-2 

M-1 through ii-8 



6-1, 6-2 

6- 5, 6-6 

7- 11, 7-12 

7-19, 7-20 

A-17 through A-20 

B-1 through B-8 
B-9 , blank 

C-1 through C-6 



Insert 

iii through vi 
vii, blank 

2-1, 2-2 

4-1 through 4-6 
4-6.1, blank 
4-7, 4-8 

6-1, 6-2 

6- 5, 6-6 

7- 11, blank 
7-11.1, 7-12 

7-19, blank 
7-19.1, 7-20 

A-17 through A-22 

B-1 through B-8 



C-1 through C-6 
C-7, blank 



i-1 through i~4 



i-1 through i-4 



Honeywell disclaims the implied warranties of merchantability and fitness for a partic- 
ular purpose and malies no express warranties except as may be stated in its written 
agreement with and for its customer. 

In no event is Honeywell liable to anyone for any indirect, special or consequential 
damages. The information and specifications in this document are subject to change 
without notice. 



0 j Honeywell Information Systems Inc., 1983 



2/83 



File Wo. : 1L63, 1U63 
CC75-01A 



INDEX 



A 



active channel 5-2 
analog signal 3-3 
answerback 2-3 
answering service 3-2 
asynchronous I/O buffer space C-5 
asynchronous line type 2-1 
asynchronous link 3-1 
attach command 1-4, 5-2 



B 



baud rate 2-3, 3-1 

automatic detection 3-5 
1200 baud 3-5 
modems 3-6 
other bauds 3-5 

bindfile segment 7-2 

bind_fnp command 1-4, 7-2 

bit rate 3-1 



C 



CDT 

see channel definition table 

channel 

addition of 5-1 
attach command 5-2 
attributes 5-3 

changing the attributes of 5-2 

changing the service type of 5-4 

changing the state of 5-2 

deletion of 5-2 

detach command 5-3 

line type 2-2 

modification of 5-1 

multiplexer C-1 

naming 1 -3 

remove command 5-3 

service type 4-6, 5-4 

inactive 5-2 

login 3-2 
terminal type 2-3 

channel definition table 1-1, 1-3, 
2-2, 2-3, 3-2, 4-1, 5-1, 7-11, 
7-27 

channel master file 4-1, 5-1, 7-11 
defaults 4-7 
example 4-8 

global statement 4-2, 4-7 



channel master file entry 4-2 

channel 

access_class statement 4-4 
answerback statement 4-5 
attributes statement 4-4 
baud statement 4-4 
charge statement 4-6 
comment statement 4-7 
dataset statement 4-6 
gener ic_destination statement 4-3 
initial_command statement 4-7 
line_type statement 4-5 
multiplexer_type statement 4-7 
name statement 4-2, 4-3 
service statement 4-6 
terminal_type statement 4-5 

FNP 

FNP statement 4-2 
hsla statement 4-2 
image statement 4-3 
Isla statement 4-2 
memory statement 4-2 
service statement 4-3 
type statement 4-2 

channel_comm_meters command 7-4 

CMF 

see channel master file 

command descriptions 
bind_fnp 7-2 
channel_comm_meters 7-4 
console_report 7-8 
cv_cmf 7-11 
display_cdt 7-12 
display_fnp_idle 7-14 
fnp_throughput 7-16 
map355 7-18 
mcs_version 7-19.1 
meter_fnp_idle 7-20 
set x25_packet_threshold 7-21.1 
sys'Eem_comm_meters 7-22 
tty_dump 7-24 
tty_lines 7-27 

communications channel 1-1 

communications link 3-1 
asynchronous 3-1 
synchronous 3-1 

communications protocol 1-4, 2-1 

ccms! Siaters_ subroutine 5-2 

concentrator 1-2 

config deck 1-4, 5-5 

configuration 1-3 

console_report command 7-8 

control tables module 1-4 

core image 1-4 

core image segment 7-2 



i-1 



CC75-01B 



cv_cmf command 1-1, 5-1, 7-11 
D 

dataset 
see modem 

detach command 1 , 5-3 

dialup link 3-2 

digital signal 3-3 

display_cdt command 4-1, 7-12 

display_fnp_idle command 7-11 

F 

FNP 

see Front-End Network Processor 

FNP core images 6-1 
bindfile 6-4 

key words 6-4 

sample 6-6 
modifying 6-1 
optional modules 6-2 
required modules 6-2 
using 6-1 

FNP global statements 4-7 
FNP_required up_time 4-7 
spare_channeT_count 4-8 

fnp_throughput command 7-16 

foreign system connections A-22 

Front-End Network Processor 1-1, 1-3, 
1-4, 3-1, 4-1, 5-1, 5-5 

crash notification 5-6 

full duplex 3-2 

G 

G115 I/O buffer space C-5 

GCOS Environment Simulator 7-18 

generic destination A-22 

H 

half duplex 3-2 
hangup operation 3-2 
hardwired link 3-2 
HASP I/O buffer space C-5 
HASP workstations A-1 
host systems A-1 

I 

IBH 3271 terminals A-5 

IBM2780 and IBM3780 I/O buffer space 
C-6 

IBM3270 I/O buffer space C-6 



inactive channel 5-2 

initialization 1-3 
multics command 4-8 
startup command 4-8 

install command 4-1, 5-1 



L 



LCT 

see logical channel table 
line protocol 4-6 

line type 1-4, 2-1, 2-2, 2-3 

characteristics 2-1 

listen operation 3-2 
load_mpx command 4-7, 5-1 
logical channel table C-1 
login command 2-3 



M 



niap355 assembler language 7-18 

Bap355 command 7-18 

mcs_version command 7-19.1 

memory configurator B-1 
DN355 B-1 
DN6632 B-1 
DN6670 B-1 

DN6670 configured with at least 64K 

memory B-5 
FNP configured with 32K memory B-1 
I/O buffer values B-4 

meter_fnp_idle command 7-20 

modem 1-3, 2-1, 3-2, 3-3, 4-6 

modulator/ demodulator 
see modem 

MPX_meters_ subroutine 8-5 

multiplexer 1-2, 4-1, 5-1, 5-5, A-1 
channel C-1 
deletion of 5-5 
HASP 

multiplexer terminal types A-3 
HASP channels A-2 
HASP workstations and host systems 

FNP Core Image A-1 

multiplexer terasinai types A-l 

subchannel terminal types A-4 
IBH3270 A-5 

channels A-6 

FNP Core Image A-6 

see also FNP Core Images A-6 

multiplexer terminal types A-6 

raw3270 mode A-9 

subchannel terminal types A-B 

typing conventions A-8 
polled VIP A-10 

blank lines A-15 

channels A-10 

circumflex and tilde A-16 

dialups and hangups A-I6 

end of page A-15 

FNP Core Image A-10 

see also FNP Core Images A-10 

formfeeds A-15 

function codes A-1 4 

input size considerations A-1 3 



i-2 



CC75-01B 



multiplexer (cont) 
polled VIP 

multiplexer terminal types A-1 1 
quits A-14 

subchannel terminal types A-1 3 
tabs A-15 
so ft ware- Simula ted terminals A-16 
channels A-17 

multiplexer terminal types A-17 
X.25 network connections A-17, 
A-17.1 
channels A-1 9, A-20 
FNP Core Image A-1 9 
hardware A-1 8 
link level A-16 
packet level A-18 
software A-18 

terminal control level A-1 9 
terminal type file (TTF) A-20 



N 



names 

channel 1-3 
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X.25 I/O buffer space C-6 
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